即時壓縮有多昂貴？

我有一個服務器上的文件存儲庫，必須下載到移動設備。服務器上的文件可以在下載到設備後在服務器上更新;並且在隨後的連接中，只有修改的文件必須被下載到設備。即時壓縮有多昂貴？

我的選擇是要麼提前準備拉鍊，要麼隨時準備。爲了提前創建它們，我必須事先爲存儲庫的所有以前版本創建一個zip。爲了即時準備，我可以找出哪些文件需要下載並在運行中壓縮。

我認爲這個決定取決於在飛行中準備這樣一個拉鍊是多麼昂貴。

我的問題是：

需要多少費用來動態創建一個zip？可能有成千上萬的移動設備;它應該可以緩存一個準備好的zip文件，但我也想考慮每個連接分開的壓縮成本。這背後的目的是爲了避免在服務器上存儲歷史數據
除了動態的壓縮成本之外，還有其他的參數需要考慮嗎？

服務器運行在嵌入式tomcat進程中。

來源

2013-04-17 Miserable Variable

在這種情況下，通常最好在用戶請求它們時壓縮文件，但要暫時保存副本。這樣，您可以將保存的副本提供給請求相同文件的用戶。（但是，如果這些文件對於特定用戶是唯一的，那麼當許多用戶同時下載時，如果您的服務器超載，則可能需要搶先壓縮。） –

謝謝@LeeMeador。該文件集不是用戶唯一的，並希望能夠保存（緩存）準備好的zip文件。 –

在網絡操作（如SSH/SFTP，SSL/TLS，HTTP（S）等）中的動態壓縮不僅不會降低傳輸速度，而且會顯着增加傳輸速度！所以只要有可能，歡迎壓縮。

現在，您可以壓縮發送到通道的數據，也可以壓縮文件併發送壓縮文件。發送壓縮ZIP的問題是，在大多數情況下（流ZIP壓縮庫很少見，但它們確實存在IIRC），在壓縮ZIP文件時無法流式處理 - 您需要等待打包完成才能響應請求。這可能會造成問題，如果檔案是巨大的（幾十兆字節或更大）。好處是你可以打包文件一次，並將其保存在緩存中很長一段時間（比如一週或一個月）。

來源

2013-04-17 18:30:31

我並不需要在線（流媒體）zip;我試圖根據需要（包括使用緩存副本）在服務器上存儲歷史數據之間進行壓縮。 –

我建議你看看this presentation from Google中的幻燈片＃13。

他們使用zippy這是一個定製的zip實現，但重點是明確的：壓縮比發送數據更便宜。是的，你仍然需要發送文件，因此小文件的存儲空間較小，但大多數時間都是壓縮。

來源

2013-04-18 09:12:13 mindas

我已經意識到壓縮的好處。問題在於是否在服務器上預先準備它們（存儲歷史狀態）v/s即時創建它們（有可能的緩存） –

如果不知道數據和預算，很難回答您的問題。通常情況下，預處理（在你的情況下準備拉鍊）是一種可行的方式，但是如果你的存儲設備昂貴，那麼你可能需要看看你準備付出多少錢來降低延遲。 – mindas

存儲便宜，成本是在服務器上添加狀態信息。如果我想要預先創建zip，我需要一個從每個以前的版本到最新的delta;創建它們，我只需要服務器上的當前快照 –

即時壓縮有多昂貴？

回答

相關問題