2010-09-09 168 views
9

處理大文件是否存在最佳塊大小這樣的事情?我有一個上傳服務(WCF),用於接受數百兆字節的文件上傳。如何計算上傳大文件的最佳塊大小

我已經試驗了4KB,8KB到1MB塊大小。更大的塊大小對於性能(更快的處理)是有利的,但它以內存爲代價。

因此,有沒有辦法在上傳文件時計算出最佳的塊大小。怎麼去做這樣的計算?它是可用內存和客戶端,CPU和網絡帶寬的組合,它決定了最佳的大小?

乾杯

編輯:也許應該提及的是,客戶端應用程序將在Silverlight。

回答

6

如果您擔心資源耗盡,那麼通過根據您的系統可用內存評估您的peek上傳併發可能是最佳選擇。同時進行多少次同步上傳會是您可能進行的任何計算中關鍵的關鍵變量。所有你需要做的就是確保你有足夠的內存來處理上傳併發,這是相當微不足道的。內存很便宜,並且在達到併發將超出內存可用性的程度之前,很可能會耗盡網絡帶寬。

從性能方面來說,這不是在應用程序設計和開發過程中真正優化的東西。您必須擁有系統,用戶上傳真實文件,然後您可以監控實際的運行時性能。

嘗試與網絡的TCP/IP窗口大小相匹配的塊大小。這與您在設計時真正需要的最佳一樣。

+1

嗯,我更多的是指客戶機(我們沒有任何控制權)。如果我將塊大小設置爲1MB,則會佔用客戶機上的所有內存。但是,如果我將其設置爲低,則需要很長時間來處理。 – Fixer 2010-09-09 04:57:10

+3

哦!用客戶端機器,它更簡單。併發幾乎不存在。只要你在得到它們之後不在內存中存儲數據,你幾乎可以使用任何你想要的塊大小。任何現代客戶端,即使是手機,只要您在獲取每個塊後將數據流傳輸到存儲器,就有足夠的CPU和內存來處理幾個文件。我懷疑你會發現應用程序級別的性能在塊大小方面有顯着差異。我會用1024KB的大文件,並稱它爲一天。 – 2010-09-09 11:18:57