xml序列化的效能問題

2021-08-31 20:00:46 字數 921 閱讀 6280

最近乙個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中讀取...