DMServer性能测试问题总结

1.1 BugId=172659

bug描述	建档时间
终端回连数目为1000时，DMServer认证失败，即当终端回连数加大时，会偶尔出现认证失败的问题；	2011-07-29

【原因】计算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

bug描述	建档时间
DMServer在边进行终端回连时边接收任务，会导致接收速度变慢	2011-09-05

【原因】这个问题的原因有两方面：

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

bug描述	建档时间
smsdealer入队列数据量不对，即在某些情况下，会收到重复的自注册短信	2011-08-05

【原因】这个问题的原因是由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的结果实际就是空的，从而导致业务逻辑产生了异常。

解决方法是将上面这行代码删除，即在查询过程中不能清除使用了缓存策略的结果数据。