记一次简单压力测试及小调优(b/s)

  本系统作为接口适配系统，前有系统，后有系统，在现场集成测试中被测试人员认为性能瓶颈制造者。虽后经测试验证发现，性能瓶颈在C系统，但毕竟出现性能问题，于是准备进行一次测试，在不考虑A，C的情况下我们的系统能达到什么样的一个能力。

用户->A系统->B系统->C系统，B系统为本系统，负责接口适配。

A系统为门户系统，B为本系统负责接口适配，C系统为运营商系统。

现场反馈的情况，在双机（8G内存，CPU*4，具体参数不详）情况下，持续1小时的压力测试，只有200hits/s左右，这与我所想象的差别比较大。

本地测试环境：

硬件配置：CPU E5620  @  2.40GHz X2（16核），内存 32G
操作系统：CentOS release 5.4（64bit，内核2.6.18）
tomcat5.5,jdk1.6 64bit

 在未做任何调整情况下，单机跑30分钟200多hits/s

1、因为后端使用tomcat，所以想到的就是把线程数调大，调到1000，发现处理能力稍有上升，但不理解。

2、调整jvm参数，经过几次对新手代参数，垃圾回收算法的测试后，最终使用参数(因现场内存相对小一些，所以这里也尽量也基于现场内存来考虑)：

-Xmx4g
-Xms4g
-Xmn1g
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=3
-XX:CMSInitiatingOccupancyFraction=85
-Dcom.sun.management.jmxremote.port=8899
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

 最后三行为测试监控需要。这个参数并不完美，但相比之前将young设置较大，gc间隔时间相对长，但一次gc开销的时间完全不能接受，达到0.x秒，监控看到的CPU用来处理GC的时间也较明显。改为上述参数后，GC较频繁，但一次开销时间较少，对CPU的影响基本能忽略。

 整体heap的gc有点惨不忍睹，不过从测试来看对系统影响基本可接受。中间曾有一次大波动，为此QA来跑过来问我，为什么突然hits基本掉到0，出现一个大V。忘了告诉QA，因发现内存使用持续上升，所以做了个heap dump，heap dump会做一个full gc，同时将内存镜像写入文件。在这后我又偷偷做了个gz（拉到本地分析）

修改上述参数后，单机跑半小时可达到400hits/s，有一些提升，但还未达到目标。

2、visualvm上场，连接远程jvm 8899端口，监控到下图，让我比较意外：

  log4j占用了绝大量的cpu，tomcat http处理线程第二，第三是我们代码。为了验证log4j影响了性能，将log调到error级（这里有个前提，因为系统为接口适配系统，所以A进来的请求、出去到C的请求以及获取到的响应，返回给A的响应都需要info输出）继续监控，发现性能大大改观，见下图：

 从上图能清楚看出，现在CPU都用到该用的地方，跑30分钟下来，达到了800hit/s，出现了几个错误。现在的问题在于tomcat又占用了较多CPU，理想状态是与业务代码7/3，目前还在摸索。

3、因项目情况需要，日志还是需要输出，于是只能在log4j上想办法了，首先将console日志关闭，日志只输出到一个文件中（之前同时输出到指定文件及catalina.out）;将写日志缓存设置到8k左右。实测发现，使用AsyncAppender带来的性能提升并不明显。经过这一番折腾，稳定在600hits/s，超过合同所要求的250并发不少。

4、从日志输出上想办法，该输出的输出，不该输出或可以不输出的就不输出，同时继续把log4j输出缓存做了一些修改，改为800k，最终跑下来大概720hits/s，log4j所占cpu也到基本能接受范围。

  linux/unix资源监控工具，推荐使用ibm nmon。本人主要做开发，只能记录自己测试的一点小心得。