©Copyright 2008
Julian Simpson. All rights reserved.
英文原文: Scaling up
I was an Infrastructure Specialist at ThoughtWorks. In my role I
make sure that we are building our software so it can successfully be
deployed to production. In this series of blog posts I hope
to
pass on my top ten tips for using CruiseControl Enterprise
effectively. I'm writing these with the developers or systems
administrators in mind: the people who most often manage
CruiseControl. However, I hope that anybody who is interested
in
Continuous Integration will get something from these articles.
# 6: Scaling up
第
一件要做的事就是確保你可以同時構建你的多個項目. CruiseControl使用Java線程來管理構建和項目. 每個項目都有自己的項目線程.
而至少有一個構建線程來真正的運行一次構建. 實際上有一個構建隊列, 來調度從項目線程到發到構建線程的請求.
你要給CruiseControl足夠的構建線程來運行: 缺省情況下只有一個構建線程. 它的影響就是如果你配置了 5 個項目,
你也只能一次構建一個. 這也可以接受, 如果你只有一臺很弱的構建服務器, 或者項目之間不能和平共處.
另一方面, 如果你有強大的計算能力可以使用, 你就可以從額外的構建線程中得到提速. 正確的線程數量設置會隨著時間而變化; 不要不情愿去做性能管理來找到你的服務器的最優的設置.
Jeffrey Frederick 則明智的指出設置多于項目個數的構建線程數是沒有意義的.
在 調優你的持續集成服務時, 還有大量的其它因素可以考慮: 你的版本控制系統的速度, 你在哪里存儲你的構建產物, 日志, 等等. 今天我要提到的一個因素是硬盤帶寬. 編譯軟件是一個很耗硬盤的過程. 即使構建已經完成了編譯Java代碼和打包jar包等操作, CruiseControl還得寫日志文件. 所有這些事情很容易就會讓單個硬盤滿負荷運轉. 理想情況下你想確保你的機器能夠一次構建多個項目.
在 我很早期的一個ThoughtWorks項目中, 我們的團隊運行了兩個CruiseControl服務器, 顯然是因為最初的那個Solaris服務器太慢了. 對我來說這看起來不對勁. 于是我深入的看了一下. 依靠我的系統管理員背景, 我發現了某個硬盤100%的忙于運行操作系統, CruiseControl和構建. 我把工作負載分布到系統中的四個硬盤上, 然后那臺機器就能管理多得多的項目了.
在我后續的項目中, 這個模式不斷的重復. 以我的經驗, 沒有多少CI服務器是因為處理器過載而受到限制. 不幸的是, 一旦系統啟動并開始運行, 矯正磁盤問題通常會很痛苦. 在調優和人們開始抱怨緩慢的構建之前, 定購大量的快速的硬盤驅動器并祝自己好運.
實 現這個模式的方法是使用CruiseControl的配置文件. <log>元素用來告訴CruiseControl把日志文件寫到哪. 缺省情況下它是CruiseControl安裝目錄下的一個子目錄. 如果你修改了<log>元素的"dir"屬性, 你就能夠確保日志文件可以寫到沒有運行CruiseControl的硬盤上. 如果你使用 Ant 來構建你的代碼, 你可以使用配置文件中<ant>元素的 "antWorkingDir" 屬性來保證你的項目在另外一個硬盤上構建.
我 無法為此給出一個很好的例子, 每個CruiseControl的實例之間太不一樣了. Buildx是一個使多個安裝更一致的嘗試. 如果你看一下各個部分在硬盤上的布局方式, 你就會發現CruiseControl的安裝在/usr/share/cruisecontrol, 但是projects和logs安裝在/var/spool/cruisecontrol: 我們這么做的原因是這樣的話你就能 mount /var 目錄到另外一塊硬盤, 如果系統開始變得繁忙. 如果你想知道更多的話隨時告訴我.
另一方面, 如果你有強大的計算能力可以使用, 你就可以從額外的構建線程中得到提速. 正確的線程數量設置會隨著時間而變化; 不要不情愿去做性能管理來找到你的服務器的最優的設置.
<cruisecontrol>
<system>
<configuration>
<threads count="2" />
</configuration>
</system>
<!-- rest of config file suppressed -->
</cruisecontrol>
<system>
<configuration>
<threads count="2" />
</configuration>
</system>
<!-- rest of config file suppressed -->
</cruisecontrol>
Jeffrey Frederick 則明智的指出設置多于項目個數的構建線程數是沒有意義的.
在 調優你的持續集成服務時, 還有大量的其它因素可以考慮: 你的版本控制系統的速度, 你在哪里存儲你的構建產物, 日志, 等等. 今天我要提到的一個因素是硬盤帶寬. 編譯軟件是一個很耗硬盤的過程. 即使構建已經完成了編譯Java代碼和打包jar包等操作, CruiseControl還得寫日志文件. 所有這些事情很容易就會讓單個硬盤滿負荷運轉. 理想情況下你想確保你的機器能夠一次構建多個項目.
在 我很早期的一個ThoughtWorks項目中, 我們的團隊運行了兩個CruiseControl服務器, 顯然是因為最初的那個Solaris服務器太慢了. 對我來說這看起來不對勁. 于是我深入的看了一下. 依靠我的系統管理員背景, 我發現了某個硬盤100%的忙于運行操作系統, CruiseControl和構建. 我把工作負載分布到系統中的四個硬盤上, 然后那臺機器就能管理多得多的項目了.
在我后續的項目中, 這個模式不斷的重復. 以我的經驗, 沒有多少CI服務器是因為處理器過載而受到限制. 不幸的是, 一旦系統啟動并開始運行, 矯正磁盤問題通常會很痛苦. 在調優和人們開始抱怨緩慢的構建之前, 定購大量的快速的硬盤驅動器并祝自己好運.
實 現這個模式的方法是使用CruiseControl的配置文件. <log>元素用來告訴CruiseControl把日志文件寫到哪. 缺省情況下它是CruiseControl安裝目錄下的一個子目錄. 如果你修改了<log>元素的"dir"屬性, 你就能夠確保日志文件可以寫到沒有運行CruiseControl的硬盤上. 如果你使用 Ant 來構建你的代碼, 你可以使用配置文件中<ant>元素的 "antWorkingDir" 屬性來保證你的項目在另外一個硬盤上構建.
我 無法為此給出一個很好的例子, 每個CruiseControl的實例之間太不一樣了. Buildx是一個使多個安裝更一致的嘗試. 如果你看一下各個部分在硬盤上的布局方式, 你就會發現CruiseControl的安裝在/usr/share/cruisecontrol, 但是projects和logs安裝在/var/spool/cruisecontrol: 我們這么做的原因是這樣的話你就能 mount /var 目錄到另外一塊硬盤, 如果系統開始變得繁忙. 如果你想知道更多的話隨時告訴我.