日志设置优化
某行CC项目组的压力测试经验
问题现象:
项目组描述:在单请求情况下,一个交易(包含本地数据库插入操作、挡板主机模拟访问)耗时35ms。50并发的情况下平均每个交易耗时600ms以上。客户对这样的测试结果不满意。
问题分析:
经过现场分析考察,发现下列问题:
1.日志级别设置过低:目前压力测试过程中的文件日志(log4j)级别设置为debug/info/warn等,导致文件日志量非常大。
2.后台连接服务的连接池设置较小:
后台通讯的tcpipservice没有设置maxConnection参数(参见测试用例的ss.xml文件),即使用原有默认设置10个,在高并发的情况下可能形成瓶颈。修改后该参数设置为50。
综合修改上述几点后,再次测试单请求访问时间降为29ms,50并发的情况下,平均交易时间降为153毫秒,100用户并发260ms
问题现象:
项目组描述:在单请求情况下,一个交易(包含本地数据库插入操作、挡板主机模拟访问)耗时35ms。50并发的情况下平均每个交易耗时600ms以上。客户对这样的测试结果不满意。
问题分析:
经过现场分析考察,发现下列问题:
1.日志级别设置过低:目前压力测试过程中的文件日志(log4j)级别设置为debug/info/warn等,导致文件日志量非常大。
2.后台连接服务的连接池设置较小:
后台通讯的tcpipservice没有设置maxConnection参数(参见测试用例的ss.xml文件),即使用原有默认设置10个,在高并发的情况下可能形成瓶颈。修改后该参数设置为50。
综合修改上述几点后,再次测试单请求访问时间降为29ms,50并发的情况下,平均交易时间降为153毫秒,100用户并发260ms
内存泄露与Context回收
在N多地方作压力测试时,都碰到过内存泄露的问题。具体到EMP应用,引起压力测试的问题经常是部分Context没有回收。
实例:某银行网银系统
问题现象:压力测试过程中,内存出现泄露(内存占用越来越大)
问题分析:
通常context都是自动得到的(
实例:某银行网银系统
问题现象:压力测试过程中,内存出现泄露(内存占用越来越大)
问题分析:
通常context都是自动得到的(