在silverlight forum看了一個關於如果提高wcf性能的貼,覺得很受用。顯然對於分布式應用程序,似乎沒有什麼比提高客戶端的響應速度更值得關切。之後查找了相關資料,並動手做了一些練習.當然我也看到了黎波的那個關於提升web service性能實戰的pdf.
1.datasetsurrogate加速webservice: 關於datasetsurrogate我查過msdn,顯示這個類所在的命名空間Microsoft.Synchronization.Data，不過在.net framework 3.5sp1該命名空間寫已經沒有該類.ms在.net 1.1出的這個datasetsurrogate類,似乎已經被拋棄.不過在ms網站依舊可以下載得到datasetsurrogate 代碼,需要自己編譯生成dll。
2.在使用web service時候,常常習慣返回dataset。不過對於dataset有一個RemotingFormat屬性，可以設置為 serializationFormat.Xml和serializationFormat.Binary關於2者的區別在於序列化的深度,我的理解是 xml格式早晨冗余,binary格式傳輸效率好,但是會把數據體積變得更龐大，這樣反倒影響了性能,但是轉化為binary可以對數據加密傳輸.因此要利用binary本身的傳輸優勢,壓縮顯得非常重要.下面是測試結果
未命名 這個測試時從數據庫讀取2w條數據，分別采取下列措施：
getCompressBytes:讀取數據到dataset,用二進制序列化後,采用gzip壓縮,返回
getDataSetBytes:讀取數據到dataset,用二進制序列化(不是設置RemotingFormat屬性值),返回
getDataSetBytes:讀取數據到dataset,返回
從上面看似乎結果並不是上面所說的那樣，我的解釋是由於測試時間是從調用getComPressBytes開始到結束，中間的時間包括用二進制序列化，以及壓縮的過程，而我關心的只是傳輸的過程,壓縮應該說是一個耗時的過程.
3.SharpZipLib
gzip壓縮是.net System.Io命名空間下的一個壓縮算法.不過我更關心SharpZipLib開源的壓縮框架,支持Zip,Gzip,Tar,bZip2.多余的不說下面看看SharpZipLib 和gzip的壓縮率以及整個過程的
SharpZipLib壓縮:
[WebMethod(Description = "4.將list對象用Binary序列,並用ICSharpCode.SharpZipLib壓縮後返回")]
public byte[] getDataListSharpZipComPressBytes()
{
// byte[] buffer = getTestData(fileName);
IList<Users> list = getTestDataList();
/*----*/
BinaryFormatter ser = new BinaryFormatter();
MemoryStream ms = new MemoryStream();
ser.Serialize(ms, list);
byte[] buffer = ms.ToArray();
/*----*/
byte[] zipbuffer = new CompressionHelper(CompressionLevel.BestSpeed).CompressToBytes(buffer);
//ms.ToArray();
return zipbuffer;
}
public byte[] CompressToBytes(byte[] bytesToCompress)
{
MemoryStream ms = new MemoryStream();
Stream s = GetOutputStream(ms);
s.Write(bytesToCompress, 0, bytesToCompress.Length);
s.Close();
return ms.ToArray();
}
當然啊在實際應用中，我們將數據壓縮之後，通常在客戶端還需要進行解壓縮,反序列化而且很多時候傳輸的不是dataset，而是list<T>或單個對象，或一些值類型。
buffer = client5.getDataListSharpZipComPressBytes();//通過wcf獲取壓縮後的list
buffer = new CompressionHelper(CompressionLevel.BestCompression).DecompressToBytes(buffer);//解壓縮
IList<webServiceTest.Users> list = DataFormatter.RetrieveDataList(buffer) as IList<webServiceTest.Users>;//轉化為實際要用的list<Users>
我和一個資深的同事聊起關於wcf數據壓縮的話題，他提出了一個問題，就是在實際應用中,對於壓縮blob(大數據)就值得考慮,其實是一個非常耗 cpu資源的事情,而且還不支持多核優化，就是說不管你服務器是幾核，實際使用的是仍然是單核，因此對於服務器的內存，還是cpu都是極大的考驗。不過對於數據壓縮耗cpu資源這個很容易體會,我讀取一個175m的pdf文件用SharpZipLib1壓縮(zip)cpu,，內存使用率暴漲，這和直接用 winrar效果一樣，不過對於cpu倒不是如同事說的單核運行。
