2011-09-08 104 views
6

這個問題從我昨天從我的問題中學到的標題爲using git to distribute nightly builds繼續。使用bittorrent協議每晚分發和CI編譯

在上述問題的答案中很明顯,git不適合我的需要,並被鼓勵使用BitTorrent重新檢查。


短版

需要夜間分發構建每天早上人70+,想用混帳BitTorrent的進行負載平衡的轉移。

龍版

NB。如果您已閱讀我的previous question,則可以跳過以下段落。

每天早上我們需要將我們每晚的作品分發給70多人(藝術家,測試人員,程序員,製作人員等)的工作室。到目前爲止,我們已經將構建版本複製到服務器,並編寫了一個同步程序來獲取它(使用下面的Robocopy);即使設置了鏡像,傳輸速度也會慢得令人無法接受,因爲在高峯時間同步需要長達一小時或更長時間(非高峯時間大約爲15分鐘),這指出硬件I/O瓶頸以及可能的網絡帶寬。

我知道什麼到目前爲止

我迄今發現:

  • 我發現有關BitTorrent protocol這是一個有趣的閱讀維基百科的優秀條目(我先前只知道種子如何工作的基礎知識)。在客戶端 - 服務器握手之後發生的BITFIELD交換中也發現這個StackOverflow answer

  • 我還發現MonoTorrent C# LibraryGitHub Source),我可以用它來編寫我們自己的跟蹤器和客戶端。我們不能使用現成的追蹤器或客戶端(例如uTorrent)。

問題

在我最初的設計,我有我們的編譯系統創建的.torrent文件加入它來跟蹤。我會超級種子洪流使用我們現有的構建鏡像。

使用這種設計,我需要爲每個新版本創建一個新的.torrent文件嗎?換句話說,是否有可能創建一個「滾動」。torrent如果構建的內容只改變了20%,那麼需要下載的所有內容到獲取最新的

......其實。在寫上面的問題,我認爲我會需要創建新的文件然而我將能夠下載到用戶計算機上的相同位置和散列會自動確定什麼,我已經有了。它是否正確?

響應於評論

  1. 對於完全新鮮同步整個構建(包括:遊戲,源代碼,本地化數據,和光盤圖像爲PS3和X360)〜37000頁的文件和在未來只需 50GB以下。隨着生產的繼續,這將會增加。此同步需要29分鐘才能完成,此時只有2個其他同步正在發生,如果您認爲早上9點我們會有50多個人想要獲得最新時間,那麼這個同步會出現低峯。

  2. 我們已經調查了與IT部門的磁盤I/O和網絡帶寬;結論是網絡存儲正在飽和。我們也將統計數據記錄到同步數據庫,這些記錄甚至顯示少數用戶正在獲得不可接受的傳輸速率。

  3. 關於未使用過的,現成的客戶,它具有像的uTorrent安裝在考慮到其他項目可以容易地使用程序下載的用戶機應用程序中的法律問題。我們也希望有一個自定義的工作流程來確定你想要獲得哪個版本(例如,只有PS3或X360取決於你的桌面上有什麼DEVKIT)並且有可用的新版本的通知等。使用MonoTorrent創建客戶端不是部分我很關心。

+1

你分發的文件的大小是多少?你有沒有試過一個很好的壓縮?您也可以使用二進制比較工具對付以前的版本,該補丁對於幾乎每個人都是足夠的(其他人將下載完整的軟件包)。 – Guillaume

+1

你確定改變協議/工具會解決問題嗎?你有沒有對你的網絡上要發佈的內容進行真實的數學分析,比如你的硬件,網絡帶寬等等。對於這個問題,你是否檢查過文件系統系統緩存(cf:http://blogs.technet。 COM/b/askperf /存檔/ 2007/05/08 /慢大文件拷貝issues.aspx)? –

+0

我真的不明白爲什麼你不能使用現成的客戶端,你是否也在運行室內網頁瀏覽器和文字處理器? – grapefrukt

回答

6

對於是否需要創建新的.torrent,問題的答案是:

但是,根據您的數據的佈局一點,你可以做一些簡單的半增量更新。

如果您發佈的數據是個別文件的大量集合,每個構建的某些文件可能已更改,您可以簡單地創建一個新的.torrent文件並讓所有客戶端將其下載到與舊文件相同的位置像你建議的那樣)。客戶端首先會檢查磁盤上已存在的文件,更新已更改的文件並下載新文件。主要缺點是刪除的文件實際上不會在客戶端被刪除。

如果你正在寫反正你自己的客戶端,在文件系統,不在的.torrent文件中刪除的文件是一個相當簡單的步驟,可以單獨完成。

如果你發佈的圖像文件,自認爲保持不變跨版本可能已移動了位,從而產生不同的片哈希這是行不通的。

我不一定會推薦使用超級種子。根據您使用的超級播種實施的嚴格程度,它實際上可能會損害傳輸速率。請記住超級播種的目的是儘量減少種子發送的字節數,而不是最大化傳輸速率。如果你所有的客戶都表現得很好(比如先使用稀有),那麼這件作品的發行也不應該成爲問題。

另外,要創建一個洪流並對一個50Gb的洪流進行散列檢查,會給驅動器帶來很多負擔,您可能需要對您使用的bittorrent實現進行基準測試,以確保其性能足夠。在50 GiB時,不同實現之間的差異可能很大。

0

只是想把另一個選項加入組合中,你考慮過BITS嗎?不是自己使用它,而是從閱讀文檔支持分佈式peer caching model,這聽起來像它會實現你想要的。

不足之處在於它是一種後臺服務,所以它會放棄網絡帶寬以支持用戶啓動的活動 - 對用戶來說很好,但如果您急需一臺機器上的數據,可能不是您想要的。

不過,這是另一種選擇。

+0

感謝您的建議。我們看了一下BITS(後臺智能傳輸服務),並可能將其用作短期解決方案。 – Dennis

+1

BITS很適合作爲後臺下載程序**但是**根據文檔:_「BITS 3.0:從Windows 7開始,不建議使用BITS 3.0對等緩存模型如果安裝了BITS 4.0,則BITS 3.0對等緩存模型爲更多信息,請參見Peer Caching。「_ –

+0

@Hightechrider:感謝有關BITS緩存模型的其他信息。 – Dennis

3

只想添加,請過目一些非BitTorrent的建議:

  • 如果每晚構建之間的變化並不顯著,您可以使用rsync,以減少網絡流量,並降低花時間複製構建。在以前的公司,我們使用rsync將版本提交給我們的發佈者,因爲我們發現我們的光盤映像沒有改變很多構建。

  • 您是否考慮過簡單地交錯複製操作,以便客戶不會減慢彼此的傳輸速度?當我們做里程碑分支時,我們一直在內部使用一個簡單的Python腳本:腳本進入休眠狀態,直到指定範圍內的隨機時間,喚醒,下載並檢出所需的存儲庫並運行構建。用戶在離開當天的工作時運行腳本,當他們返回時,他們有一切準備好的新副本。

2

您可以使用BitTorrent sync這是一種替代dropbox但在雲中沒有服務器的方式。它允許您同步任意數量的任意大小的文件夾和文件。與幾個人,它使用Torrent協議相同的算法。您可以創建只讀文件夾並與其他人共享密鑰。此方法不需要爲每個構建創建一個新的torrent文件。

+0

我剛纔剛剛閱讀過'\ .'上的同步以及在過去6個月中如何傳輸1PB的數據。但是,我並沒有立即想到我可以用於這個目的。謝謝! – Dennis