DMServer性能测试问题总结

港控/mmm° 2022-04-17 06:17 188阅读 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>**

。。。

</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"/>

因此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)) \{