DMServer性能测试问题总结 港控/mmm° 2022-04-17 06:17 154阅读 0赞 ## 1.1 BugId=172659 ## <table> <tbody> <tr> <td> <p><strong>bug描述</strong></p> </td> <td> <p><strong>建档时间</strong></p> </td> </tr> <tr> <td> <p>终端回连数目为1000时,DMServer认证失败,即当终端回连数加大时,会偶尔出现认证失败的问题;</p> </td> <td> <p>2011-07-29</p> </td> </tr> </tbody> </table> 【原因】计算MD5的工具类方法com.xxoo.dm.odomain.framework.tools.MD5\#digest有问题,原因是不支持多线程处理。原来的代码如下: public static byte\[\] digest(byte\[\] data) \{ **md.reset(); //md实例是不支持多线程的** return md.digest(data); \} 错误原因是MessageDigest类不支持多线程,现改成了如下的实现方式: public static byte\[\] digest(byte\[\] data) \{ return DigestUtils.md5(data); \} ## 1.2 BugId=176680 ## <table> <tbody> <tr> <td> <p><strong>bug描述</strong></p> </td> <td> <p><strong>建档时间</strong></p> </td> </tr> <tr> <td> <p>DMServer在边进行终端回连时边接收任务,会导致接收速度变慢</p> </td> <td> <p>2011-09-05</p> </td> </tr> </tbody> </table> 【原因】这个问题的原因有两方面: 1. DMService模块和DMServer模块同时使用了一个logger的appender来输出日志,这样会造成两边有锁等待的现象; 2. DMService模块和DMServer模块同时使用了一个EJB的Locator,而这个实例内部也是有锁的,因此也会造成锁等待的情况出现; 现在的解决方法: 1. 修改log4j.xml,修改成了如下的配置,粗体是新增加的: **<logger name="com.xxoo.dm.odomain.dms" additivity="false">** **<level value="DEBUG"/>** **<appender-ref ref="FILE\_EJB"/>** **<appender-ref ref="FILE\_EJB\_ERR"/>** **</logger>** 。。。 <appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="./log/dmserver.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="\[%-5p\] \[%d\] \[%t\] method:%c%n%m%n"/> </layout> </appender> **<appender name="FILE\_EJB" class="org.apache.log4j.DailyRollingFileAppender">** **<param name="File" value="./log/dmservice.log"/>** **<layout class="org.apache.log4j.PatternLayout">** **<param name="ConversionPattern" value="\[%-5p\] \[%d\] \[%t\] method:%c%n%m%n"/>** **</layout>** **</appender>** 2. 拆分成使用两个EJB的Locator: update\_udpairinfo\_ejb\_config.xml 给DMServer的HTTP模块使用; udinfomanagement\_ejb\_config.xml 给DMService模块使用; 分开成两个配置文件是因为JNDIServiceLocator-1.0.0.jar对同一个配置文件会生成一个对象锁,当两个模块都需要调用UDM的EJB时,就会存在锁等待问题,改成两个就不会出现这个问题了。 ## 1.3 BugId=173444 ## <table> <tbody> <tr> <td> <p><strong>bug描述</strong></p> </td> <td> <p><strong>建档时间</strong></p> </td> </tr> <tr> <td> <p>smsdealer入队列数据量不对,即在某些情况下,会收到重复的自注册短信</p> </td> <td> <p>2011-08-05</p> </td> </tr> </tbody> </table> 【原因】这个问题的原因是由jvm的Full GC造成的。 smsdealer模块从短信前置机接收短信后,需要向短信前置机回复响应应答,这个过程是有一个超时时间T的,当超过这个规定的超时时间,短信前置机还没有收到响应应答包,则短信前置机认为这条短信没有发送成功,就会将这条短信重新加入待发送的短信队列。而当jvm执行Full GC时,就会造成一定时间的停顿,若这个时间超过了上述规定的T,就会出现收到重复短信的问题。 目前的做法是将短信前置机的接收超时时间\[RecvTimeOut=15\]从15秒改成了60秒。 ## 1.4 MyBatis缓存问题 ## 问题:由于对ParamConfigRule.xml使用了缓存,即如下设置: <cache-ref namespace="com.xxoo.dm.odomain.dms.dao.CommonDSUtilsDao"/> <!--此命名空间的缓存策略配置如下--> <cache eviction="LRU" size="5000" flushInterval="120000" readOnly="true"/> 因此mybatis会对此sqlmap文件中的所有select使用缓存,即查询结果会保存在缓存中,并且下次查询时会先从缓存中获取数据。 由于当时写代码的时候未考虑已经使用了缓存,因此加入了这样一行代码(见如下的粗体字): ruleId = ruleIdList.get(0); queryParamConfigRuleMap.put("ruleId", ruleId); tmpParamConfigRuleList = (List<ParamConfigRule>) sqlSession .selectList("com.ailk.dm.odomain.dms.dao.ParamConfigRuleDao.getParamConfigRules", queryParamConfigRuleMap); if ((tmpParamConfigRuleList == null || tmpParamConfigRuleList.size() == 0)) \{ throw new ParamConfigRuleNotExistsException("ParamConfigRule Not Exists with modelId=" + modelId \+ ", swv=" + swv + ", funcTypeId=" + funcTypeId); \} paramConfigRuleList.addAll(tmpParamConfigRuleList); **tmpParamConfigRuleList.clear();** 上面这一行粗体的代码会将当前查到的结果从缓存中删除,故下次调用此方法时,tmpParamConfigRuleList的结果实际就是空的,从而导致业务逻辑产生了异常。 解决方法是将上面这行代码删除,即在查询过程中不能清除使用了缓存策略的结果数据。
还没有评论,来说两句吧...