我們將CruiseControl與StarTeam服務器一起使用，並遇到StarTeam服務器崩潰的問題。我們想知道我們是否打太大的服務器。在3臺CruiseControl機器和總共約30個項目中，我們正在登錄StarTeam並每隔一分鐘左右檢查一次修改。我們的大部分項目都有大約20,000個文件。有沒有人對StarTeam這種場景中的性能限制有經驗？使用CruiseControl（StarTeam或替代品）時的版本控制服務器性能
我對CruiseControl與其他版本控制系統（例如TFS，Perforce，SVN等）的性能指標也感興趣......使用CruiseControl時是否存在可伸縮性問題以及大量項目文件？
我有一些使用Star Team進行持續集成的經驗 - 儘管使用了TeamCity，而不是CruiseControl。在我們的例子中，從TeamCity到StarTeam的定期連接幾乎沒有註冊成爲我們性能監控的一個小點。
你看過服務器上的StarTeam日誌文件嗎？ - 通常位於代碼庫或配置單元的根目錄中。我通常發現日誌足以解決任何問題。
現在日誌文件只是顯示我們的服務器每隔幾分鐘記錄一次（15個項目包含20分鐘的修改集定時器）。日誌不顯示任何結賬活動，只是登錄。我得到的故事是「這太頻繁登錄了！」 – 2008-11-11 21:56:24
你要考慮使用 「複合改性集」 如下所述：
不StarTeam中支持 「觸發器」 ？您不必讓CruiseControl機器每分鐘檢查一次存儲庫以進行更改，而是讓您的StarTeam機器通過觸摸文件讓CruiseControl知道何時更改了代碼。
基本上，當對項目進行更新時，VCS會觸及CruiseControl監視的文件（如project-a-update.txt）。一旦發現該文件有變化，CruiseControl知道要花費更多時間從VCS進行更新。因此它每N分鐘爲每個項目輪詢一個文本文件，而不是整個存儲庫。
據我所知，StarTeam不支持觸發器。 CruiseControl.NET StarTeam任務僅支持輪詢，並且我沒有在StarTeam本地支持觸發器的任何地方看到任何證據。
雖然將StarTeam推向極限，但我遇到了完全相同的問題。我不確定，但我開始認爲崩潰問題與同時訪問有關，因爲當開發人員以及CruiseControl高度積極地開展項目時，問題會更頻繁地發生。
輪詢更改的懲罰也變得非常重要。更糟糕的是，罰款增加了一倍。對StarTeam的第一次調用是調用「hist」來獲取報告的變更集並觸發構建，然後調用「co」再次檢查整個源代碼樹並檢查任何過期或丟失文件。如果任何人都可以提出一種在StarTeam項目周圍創建觸發器的方法，那麼我會很樂意嘗試一下。
我能找到的額外信息。
StarTeam並不總是斷開用戶（或CruiseControl訪問情況下的代理），並且可能導致爲同一用戶/代理創建數十個打開的連接/登錄。不幸的是，很難確認這是否是一個相關問題，因爲我無法可靠地重載服務器。
我們使用的是沒有MPX的舊版StarTeam。我想知道是否有人在支持MPX方法的不同持續集成環境中使用StarTeam。
首先，我沒有StarTeam的經驗！儘管我有CruiseControl和顛覆的經驗。
您可以將您的日程安排間隔改爲比1分鐘更不積極的活動 - 通常需要3-5分鐘才能檢查項目是否需要建設。但我接受可能有一個原因，你需要經常檢查。
顛覆規模很好。這是因爲每次巡航檢查是否有更新時，只要將本地版本號與項目的遠程版本號進行比較，就不需要檢查每個文件。因此該檢查的速度不受項目中文件數量的影響。
我希望這可以幫助你。
我們幾個活動項目運行CC時，最大的性能改進是安裝在同一臺機器上的MPX緩存代理並確保它是存儲文件屬性和內容。 （當然，這並確保在該版本使用ccache的。）
觸發器的想法存在於StarTeam中SDK，但我不知道它是如何集成與CC。要檢查是否需要構建，我們將最後一次從服務器拉出到一個乾淨的目錄中，並使用stcmd列表比較更改。這非常快。
您是否認爲由於您從這些項目加載的大量文件或大量修改並歸還給StarTeam存儲庫的文件而導致文件崩潰？ – VonC 2008-11-05 07:58:05
不幸的是，日誌並沒有太大的幫助 - 至少是目前設置的方式。他們只是顯示登錄次數 - Borland說這是「太多了」。但是，這與CI有些不兼容。而且，我不相信只要登錄就會像這樣下載服務器。 – 2008-11-11 21:59:58