我目前正在開發一個項目，通過WCF服務傳遞一些地理數據。這些數據的大小有時會增加（2-4mb，有時甚至更多）。爲了幫助減少線路上數據的大小，我們最初在IIS上啓用了gzip壓縮功能（這有效）。唉，在測試中，我們發現我們使用的一個代理服務器使得這個毫無價值。IIS壓縮vs手動GZIP
因此，我決定在將數據發送出我們的服務之前先對數據進行壓縮。我在WCF和Silverlight客戶端都使用SharpZipLib。它運行良好，我們的數據從大約2.9MB縮減到大約400KB，但是IIS壓縮能夠將事情進一步降低。
現在我很好奇......
是否有IIS的GZIP壓縮，使得它壓縮更好後面的任何祕密武器？
是否有更好的壓縮算法可以使用？
我玩弄了一點點的各種按壓，然後它在我身上曙光。 WCF端點設置爲使用binaryEncoding。這意味着IIS將採用二進制編碼的數據並將壓縮應用於此。
在我的情況下，我使用標準的DataContractSerializer和MemoryStream對數據進行了序列化。然而這個吐出了XML。
我們發現的最佳解決方案是在我的DataContractSerializer中使用BinaryDictionaryWriter。這給了我二進制編碼的數據，然後我可以使用GZIP進行壓縮。最終結果比我們用IIS獲得更好的壓縮效果。（使用此方法，通過IIS到500K的順序爲500K）
您可以在下面的文章中看到如何使用BinaryDictionaryWriter的示例。答案低於覈准答案。 How to transfer large amount of data using WCF?
去看看現在從端點刪除二進制編碼的效果，看看是否值得多餘的「東西」的性能。
1）是的，有一個祕密的醬，但我不知道它是什麼。
但是，這是我真正想說的話：
2）您實現更高的壓縮的慾望是拖慢您的網站的風險。不要這樣做。微觀優化在這個層面沒有幫助。
在 IIS GZip壓縮後面是否有任何祕密醬油，使其 壓縮更好？
在SharpZipLib中，您可以使用SetLevel(9)（使用zip時）設置爲最大壓縮。但是，您必須記住，當您通過IIS進行壓縮時，整個有效負載將得到壓縮，並且當您執行自己的操作時，它只是有效負載的一部分。所以IIS總是能夠稍微壓縮一些。
有沒有更好的壓縮算法可以使用？
通過IIS，不是真的。通過HTTP只能使用如此多的壓縮方法：http://en.wikipedia.org/wiki/HTTP_compression。
自定義壓縮，你可以嘗試7zip，lzh等 - 任何你可以找到一個庫或自己寫。這很大程度上取決於您正在歸檔的內容，因爲不同的有效負載壓縮方式不同。我會馬上嘗試使用內置的sharpziplib（bzip2）。我也會嘗試7zip (possible with c#)
我們正在考慮刪除http壓縮，因爲它不適用於一半的情況（代理解壓縮並且無法重新壓縮）。我們與支持團隊合作過，並且他們在這種情況下無法協助使用http壓縮因此目前它的目標是手動完成。我爲Gzip設置了SetLevel（9），但沒有太多改進。郵編迴應更好嗎？ – 2010-11-02 15:52:16
我不同意：如果傳輸時間是大部分客戶端等待時間（並且有4mb的有效負載，這很可能），但這根本不是微觀優化。雖然可以逐步增加這種轉移方式，但快速修改壓縮方案可能會節省數週的重新設計，使應用程序可以部分轉移和更新。 – 2010-11-02 15:42:26
我會照顧你的專業知識。但是，我們沒有看到通過將壓縮級別設置得更高而看到很多改進，因爲正如您所指出的那樣，並非整個有效負載正在被壓縮。我沒有看到花費更多時間進一步壓縮數據的好處。當然，我從我們自己的經驗中發言，但它只是一個網站。 – 2010-11-02 16:02:09