xml序列化的效能問題

最近乙個web模組在做效能測試，用lr一壓，發現tps很低，還不到15。

問題很嚴重，雖然達到了需求中規定的要求，但是發現實在有點對不起觀眾。

決定對**進行分析，我開始一段的一段的進行分析，檢視執行時間。後來老大用jprofile分析，更快，看樣子我有點土了。

很快我把問題定位在xml的序列化上，因為請求的引數都是xml報文，而我們使用的是castor來進行反序列化和序列化。發現消耗在這段的時間佔總時間的一半，感覺不對勁。

後來我就直接寫了個簡單的測試例子，用jmeter來壓，也很慢，然後我找網上的xstream來做同樣的事情，效能比這個高10倍左右，看樣子是castor對多執行緒支援不好，高併發下效能不行。

對比castor和xstream兩個開源的元件序列化和反序列化xml的效能。

部署在weblogic上的例子，100個執行緒迴圈100次，以下是使用jmeter測試後的聚合報告截圖：

castor:

xstream:

xstream的throughput的值最高能達到300.

通過對比，可以發現castor的效能存在問題。

後來察看castor的文件，發現在個文件（xml-best-practice.html）有對效能說明；

主要是說要對descriptor classes 這種物件進行快取，還好castor有這種機制，只要使用

xmlcontext物件來建立(un)marshaller例項就行。具體看下面的**：

private final static xmlcontext xmlcontext;

static );
xmlcontext.setproperty("reuseobjects", true);
} catch (resolverexception e) 
}

xml序列化的效能問題

最近乙個web模組在做效能測試，用lr一壓，發現tps很低，還不到15。問題很嚴重，雖然達到了需求中規定的要求，但是發現實在有點對不起觀眾。決定對 進行分析，我開始一段的一段的進行分析，檢視執行時間。後來老大用jprofile分析，更快，看樣子我有點土了。很快我把問題定位在xml的序列化上，因為請求...

Xml序列化和反序列化

1.xmlserializer 類 該類用一種高度鬆散耦合的方式提供序列化服務。你的類不需要繼承特別的基類，而且它們也不需要實現特別的介面。相反，你只需在你的類或者這些類的公共域以及讀 寫屬性裡加上自定義的特性。xmlserializer 通過反射機制讀取這些特性並用它們將你的類和類成員對映到 xm...

XML序列化和反序列化

閱讀目錄 回到頂部 由於.net framework針對xml提供了很多api，這些api根據不同的使用場景實現了不同層次的封裝，比如，我們可以直接使用xmltextreader xmldocument xpath來取數xml中的資料，也可以使用linq to xml或者反序列化的方法從xml中讀取...