壓縮XML指標。

Question

我有一個客戶端服務器應用程序，它通過TCP/IP從客戶端向服務器發送XML，然後向其他客戶端廣播。我如何知道通過壓縮XML而不是通過常規流發送的最小尺寸的XML可以保證性能的提高。

這個或者例子有什麼好的指標嗎？

Answer 1

Xml通常壓縮得很好，因爲它往往有很多重複。

另一種選擇是交換爲二進制格式; BinaryFormatter或NetDataContractSerializer是簡單的選項，但與xml相比，它們都是非常不兼容的（例如使用java）。

另一種選擇是可移植的二進制格式，如谷歌的「協議緩衝區」。我維護一個名爲protobuf-net的.NET/C＃版本。這被設計爲與常規.NET方法（如XmlSerializer/DataContractSerializer）並行兼容，但比xml小得多，並且對於序列化和反序列化都需要更少的處理（CPU等）。

This page顯示了XmlSerializer，DataContractSerializer和protobuf-net的一些數字;我想到它包括統計數據/無壓縮，但他們似乎已經消失...

[更新]我應該說 - 在QuickStart項目中有一個TCP/IP示例。

Answer 2

通過一切手段總是壓縮它。

它將爲您帶寬超過2個標籤的任何東西。

Answer 3

要確定壓縮對您是否有任何好處，您需要運行一些使用實際或預期數據類型的測試，這些數據可能會流過您的系統。

希望這會有所幫助。

Answer 4

一個鬆散的度量標準將壓縮大於單個數據包的任何東西，但這只是挑剔。

沒有理由在應用程序內部不要使用二進制格式 - 無論需要多長時間壓縮，網絡開銷將比壓縮慢幾個數量級（除非我們談論的速度很慢設備）。

如果這兩個建議不讓你放心，你可以隨時找到要壓縮的點。

Answer 5

在我們所做的測試中，我們發現了巨大的好處，但請注意CPU的含義。

在我工作的一個項目上，我們向運行.NET的客戶端發送了大量的XML數據（> 10 meg）。 （我不建議這是做事情的一種方式，這只是我們發現自己的情況!!）我們發現，由於XML文件足夠大，Microsoft XML庫無法解析XML文件（機器用完了的內存，即使在機器上> 1 gig）。更改XML解析庫最終有所幫助，但在此之前，我們對我們傳輸的數據啓用了GZIP壓縮，這幫助我們解析了大型文檔。在我們的兩臺基於linux的websphere服務器上，我們能夠生成XML，然後相當容易地進行gzip壓縮。我認爲，有50個用戶同時做這些事情（加載大約10到20個這樣的文件），我們能夠做到這一點，大約有50％的CPU。XML的壓縮似乎在服務器上比在.net gui上處理得更好（即解析/ cpu時間），但這可能是由於使用了Microsoft XML庫的上述不足。正如我所提到的，有更好的庫更快，使用更少的內存。

在我們的例子中，我們也得到了巨大的改進 - 我們在某些情況下將50兆的XML文件壓縮到了大約10兆。這顯然也有助於網絡性能。由於我們擔心這種影響，以及這是否會產生其他後果（我們的用戶似乎在大浪中做事，所以我們擔心我們會用完CPU），我們有一個配置變量，我們可以用來打開/關閉gzip。我建議你也這樣做。另一件事：我們在將XML文件保存到數據庫中之前，還壓縮了XML文件，這節省了大約50％的空間（XML文件從幾K到幾兆，但大部分都很小）。做任何事都可能比選擇特定級別來區分何時使用壓縮更容易。