SharpZipLib 資料壓縮實戰：WCF 傳輸效能優化探討

在分散式應用中，提升客戶端回應速度至關重要。針對 WCF 效能優化，常見策略包括資料序列化格式選擇與壓縮傳輸。本文實測比較多種方案，並深入探討 SharpZipLib 開源壓縮框架的應用。

背景與測試情境

測試從資料庫讀取 2 萬筆資料，分別採取：

• getCompressBytes：DataSet 二進位序列化 → GZip 壓縮 → 傳輸
• getDataSetBytes：DataSet 二進位序列化（非 RemotingFormat） → 傳輸
• getDataSetBytes：DataSet 直接傳輸（XML 序列化）

初步結果顯示壓縮方案總耗時較長，但這包含序列化與壓縮運算時間，若單看網路傳輸量，壓縮優勢明顯。二進位序列化雖體積較 XML 小，但若不壓縮，大量資料傳輸仍是瓶頸。

SharpZipLib 實作範例

SharpZipLib 支援 Zip、GZip、Tar、BZip2 等格式。以下為伺服器端壓縮與客戶端解壓縮的核心程式碼：

// 伺服器端：List<T> 二進位序列化後以 SharpZipLib 壓縮
[WebMethod(Description = "List 物件二進位序列化並 SharpZipLib 壓縮")]
public byte[] getDataListSharpZipComPressBytes()
{
    IList<Users> list = getTestDataList();
    BinaryFormatter ser = new BinaryFormatter();
    MemoryStream ms = new MemoryStream();
    ser.Serialize(ms, list);
    byte[] buffer = ms.ToArray();
    return new CompressionHelper(CompressionLevel.BestSpeed).CompressToBytes(buffer);
}

public byte[] CompressToBytes(byte[] bytesToCompress)
{
    MemoryStream ms = new MemoryStream();
    Stream s = GetOutputStream(ms); // SharpZipLib 壓縮串流
    s.Write(bytesToCompress, 0, bytesToCompress.Length);
    s.Close();
    return ms.ToArray();
}

// 客戶端：解壓縮 → 反序列化還原 List<Users>
byte[] buffer = client.getDataListSharpZipComPressBytes();
buffer = new CompressionHelper(CompressionLevel.BestCompression).DecompressToBytes(buffer);
IList<Users> list = DataFormatter.RetrieveDataList(buffer) as IList<Users>;

效能與資源考量

資深同事提醒：壓縮大型 Blob 資料極度消耗 CPU 與記憶體，且早期版本不支援多核心平行處理。實測壓縮 175MB PDF 檔案時，CPU 與記憶體使用率暴增，效果類似 WinRAR。雖然 .NET 後續版本已改善平行度，但在高併發服務端仍需評估壓縮帶來的資源壓力與傳輸節省的平衡點。建議針對大量文字資料（JSON、XML、序列化物件）啟用壓縮，二進位媒體檔案則效益有限。