Git服務器並行/併發/多線程傳輸？

Question

在perforce中，我們可以啓用並行同步/提交，這意味着如果有200個新文件需要從服務器中提取，那麼p4v客戶端將打開5-10個到服務器的連接並將併發文件並行拉到另一個文件。這對傳輸速度有很大的改善，這意味着單線程上30Mbps的差異或8個併發線程上的240Mbps差異，特別是因爲我們的軟件倉庫每週都會收到10 GB的值。

我一直在環顧四周，看看是否有類似的東西，我可以啓用我們的Gitlab服務器，但我還沒有找到任何東西。這是我在這個主題上發現的唯一的東西，它只是一個請求git-annex：https://git-annex.branchable.com/forum/Feature_request__58___Multiple_concurrent_transfers/

有沒有人知道這是否可能，如果是的話，你會如此友善，指向我在正確的方向？

謝謝！

Answer 1

Git當前通過單個連接傳輸內容。目前不可能通過其網絡協議發送分塊內容。由於torek mentionned git會執行一些處理來減少需要傳輸的數據的大小。所以git通常會通過單一連接傳輸比最終重建的內容更少的內容。

Answer 2

只要你不是在同一時間傳送對象的一個​​（即，不這樣做the dumb way），客戶端的fetch過程中使用的客戶端和服務器之間的信息流連接，與the client sending with a series of "want/already-have"s as the server offers a series of "have"s，爲了弄清楚什麼客戶需要的對象。然後，一旦對象達成一致，服務器將這些對象聚合成一個瘦身包。這個精簡包是針對客戶已知的對象進行增量壓縮的。

對於非淺層存儲庫，服務器可以相信客戶端不僅擁有被拒絕的對象，而且擁有所有的前置對象，因此即使是相當大的對象集也會生成很小的包文件（具體取決於什麼前輩確實存在，並且服務器能夠快速壓縮這些對象）。例如，假設200個新的或更新的文件與200個以前的版本非常相似。這個瘦身包可能基本上由200套指令組成，這些指令說「複製舊的1234567...，然後在中間添加六個字節」而不是「這裏是200千兆字節的原始數據」。

這種瘦身包需要花費大量的CPU時間才能生產，但只需幾秒鐘即可在最慢的環節中進行傳輸。

顯然，如果200個新對象與任何以前的對象都不相似，也不會相互影響，增量壓縮將無濟於事。在這種情況下，瘦身包只會受益於zlib放氣壓縮產生的任何效果。

在任何情況下，提取客戶端都會收到（單個）精簡包文件，並通過從客戶端已有的對象中添加缺失的基礎，將其修復爲非精簡包。因此，作爲T0xicCode answered，只有一個文件傳輸。