xml序列化的性能问题

阳光穿透心脏的1/2处 2022-04-17 06:16 154阅读 0赞

最近一个web模块在做性能测试，用lr一压，发现tps很低，还不到15。  
  
问题很严重，虽然达到了需求中规定的要求，但是发现实在有点对不起观众。  
  
决定对代码进行分析，我开始一段的一段的进行分析，查看执行时间。后来老大用jprofile分析，更快，看样子我有点土了。  
  
很快我把问题定位在xml的序列化上，因为请求的参数都是xml报文，而我们使用的是castor来进行反序列化和序列化。发现消耗在这段的时间占总时间的一半，感觉不对劲。  
  
后来我就直接写了个简单的测试例子，用jmeter来压，也很慢，然后我找网上的xstream来做同样的事情，性能比这个高10倍左右，看样子是castor对多线程支持不好，高并发下性能不行。  
  
对比castor和XStream两个开源的组件序列化和反序列化xml的性能。  
部署在weblogic上的例子，100个线程循环100次，以下是使用jmeter测试后的聚合报告截图：  
castor: ![9183bf05-35ae-334e-988e-cb4a87cd9f4e.jpg][]

XStream:  
![c4026600-154e-3fff-a3bf-bb80b2c20d57.jpg][]

xstream的throughput的值最高能达到300.  
  
通过对比，可以发现castor的性能存在问题。  
  
后来察看castor的文档，发现在个文档（xml-best-practice.html）有对性能说明；  
主要是说要对Descriptor classes 这种对象进行缓存，还好castor有这种机制，只要使用  
XMLContext对象来创建(Un)Marshaller实例就行。具体看下面的代码：

private final static XMLContext xmlContext;
    
        static {
            xmlContext = new XMLContext();
            try {
                /**
                 * 请确保以下的目录下面有.castor.cdr这样的文件存在，
                 * 否则cache将不起作用
                 */
                xmlContext.addPackages(new String[]{"com.asiainfo.aidmccsupport.boss",
                        "com.asiainfo.aidmccsupport.boss.operate",
                        "com.asiainfo.aidmccsupport.boss.query"});
                xmlContext.setProperty("ReuseObjects", true);
    
            } catch (ResolverException e) {
                e.printStackTrace();
            }
            
        }

[9183bf05-35ae-334e-988e-cb4a87cd9f4e.jpg]: /images/20220417/e54afa7c1d324d67babe34b33f9387f1.png
[c4026600-154e-3fff-a3bf-bb80b2c20d57.jpg]: /images/20220417/8c5598070a3a4a4f97a93f7e0aa751a5.png