保持学习!Keep Learning!!!

我从山里来,要去看大海!

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的结果实际就是空的,从而导致业务逻辑产生了异常。

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

 

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/dmcpxy/article/details/6887449
个人分类: Java OMADM
想对作者说点什么? 我来说一句

linux 测试常用命令

2015年05月07日 3KB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭