Atlassian Crucible 在大型儲存庫上非常慢
我的公司已經對 Atlassian Crucible 進行了幾個月的試用。對於執行正常的儲存庫，使用者對該工具給出了非常積極的回饋。我遇到的問題是我們有幾個不同的項目，每個項目都有自己的儲存庫，其中一些儲存庫非常大。特別是一個儲存庫有大量分支，每個分支可能有大約 9,000 個文件。在 Crucible 中瀏覽該儲存庫非常慢。
Crucible 在 CentOS 虛擬機上執行。VM 有 4GB 的 RAM，我將 Crucible 的最大記憶體設置為 3GB，其中它目前使用的是 2GB。我在 Atlassian 的支持票中提出了這一點，他們提出了以下建議：
特別是因為您有一個相當大的 SVN 儲存庫，您可能會發現 Fisheye 將在磁碟上創建一個大型索引文件。為了幫助提高性能，您可以嘗試以下方法：
- 增加 Fisheye 的可用記憶體。
- 遷移到外部數據庫。
- 從索引中排除不需要的文件和目錄。
我已經在一定程度上嘗試了所有這些事情，但到目前為止，沒有一個有很大幫助。我最初使用內置 HSQL DB 在具有 2GB RAM 的 Windows 機器上執行 Crucible。在 CentOS 上遷移到 MySQL 後，一些儲存庫的性能得到了提升，並使 Crucible 更加穩定，但似乎對我們最大的儲存庫沒有太大幫助。在保持工具有用性的同時，我只能從索引中排除這麼多文件/分支。
在這種情況下，是否有人對如何在大型儲存庫上加速 Crucible 有任何提示，而無需投資於功能強大的硬體？
謝謝！
**編輯：**澄清一下，由於我沒有在上面明確提及，我使用的是FishEye。
**編輯 2：**自從我最初發布此內容以來，新的 Crucible 版本的性能有所提高，但無論如何它仍然不是很好。似乎這個問題影響了許多使用者，包括一些擁有比我們使用的更強大的硬體的使用者。因此，我不認為這是硬體問題，而是坩堝中固有的低效率問題。Atlassian 已意識到該問題，並將在未來的版本中進一步改進性能，因此希望這些更改能夠解決我們的問題。
**編輯 3：**我忘記了我多久以前問過這個問題，所以在我之前的編輯中，我沒有提到我們的硬體情況自最初提出以來也發生了變化。我們現在在專用的物理伺服器上執行 Crucible，仍然使用 CentOS。硬體仍然適中（4GB RAM、四核 CPU 和 RAID 1 中的雙 500GB 磁碟，帶有外部備份），但當我們離開 VM 時，我們確實看到性能略有提升。
由於遷移到 MySQL 對某些儲存庫產生了顯著影響，因此請考慮調整數據庫以進一步改進。從預設值更改某些
my.cnf值可能會產生巨大的差異。有關更多資訊，請參閱InnoDB 性能優化基礎知識。還可以通過啟用慢查詢日誌來檢查慢查詢，並在適當的地方添加索引。我的下一個猜測是網路速度：您的 Crucible 實例是否與您的 SVN 儲存庫在同一個有線本地網路上？如果可能的話，您也可以嘗試在與主記憶體儲庫相同的機器上試執行 Crucible，以消除網路延遲作為罪魁禍首。
而且我知道根據您的工作環境可能會很困難，但是在 VM 中執行 Crucible 可能無濟於事；Atlassian 在其非常簡短的“坩堝配置最佳實踐”頁面上對此進行了說明。我相信您已經遇到過它，但我也會為其他讀者提及Tuning FishEye頁面。
我也有大型項目的性能問題，但將很多緩慢歸因於 Crucible 沉重的 Web 界面。在四處點擊後尤其如此（以前查看過的評論頁面仍保留在瀏覽器視窗中，即使隱藏在視線之外）。我們的開發人員注意到切換到 Google Chrome 後速度略有提高。如果您的開發環境存在兼容外掛，還請查看Atlassian IDE 連接器。Eclipse IDE 連接器在我上一次使用它時（很多個月前）有它自己的問題，但它至少可以處理大型文件集而不會掛斷。
根據您公司的開發實踐，您可以停止掃描大量程式碼分支（假設其中許多不再處於活動狀態），並禁用已完成/已死項目的儲存庫，直到需要它們為止。我的公司在大量項目上使用非常小的團隊，所以大部分時間我們主要工作
trunk，分支是例外；因此，我們顯式添加要掃描的分支，而不是預設包括所有分支。還要確保您不會意外掃描標籤。您在 Crucible 盒子上的 CPU 使用率如何？如果您在 Apache HTTPD 後面使用 SVN，請檢查 Crucible 在大型儲存庫掃描期間消耗了多少連接。除此之外，我不確定您還能看到什麼（也許是磁碟速度？儲存庫掃描頻率？），但希望上述提示會有所幫助。