性能测试

    今天研发同事找我配合进行系统的压力测试，目前的测试结果是并发500无限循环，tps 300，怎么也上不去，怀疑压力在oracle数据库。

    测试中发现数据库的系统压力在cpu上，虽然是64核的系统，但是vmstat的r列已经是80多了，大部分cpu的压力也很高（sar -P ALL）,等待事件是latch: cache buffers chains。awr上显示平均等待40ms左右，可能问题

    （1）sql问题，逻辑读过多    -->  优化sql为主

    （2）热点块                          -->  主要考虑打散表中数据（调整pctfree或者分区）

    抓逻辑读过多的sql，果然部分走的是全表扫描。

    加索引后情况大为好转，ash显示主要事件集中在insert的cpu上了，再看看数据库的系统压力，没有，问题是并发测试还在300左右，现在初步判断瓶颈应该不在数据库上。本来与我无事了，看同事毫无思路，也跟着一起分析。

    舍去并发，1个并发1个事物，响应时间在37ms（一秒钟一个并发能响应1000/37~=27个），那并发11个就能达到300个的瓶颈了（11*27~=297个），但是前提是每个并发响应时间不衰减。

    测试（jmeter）15个并发，tps --> 200不到，说明整个系统的性能下降了不少了。

    因为我们测试是通过nginx的，查看nginx日志，大量响应码499，好吧，添加proxy_ignore_client_abort on参数，百度说是连续post，nginx拒绝。

    修改后测试，，老样子。但是ngixn的日志中的响应时间显示测试开始响应在10ms左右，但是随着压力增大，响应时间慢慢增大，最后到了4s左右。

    客户端问题？？本来是一台linux跑的jmeter，现在加一个分布式节点，如果真是jmeter问题，两台一起跑应该会好很多，结果是一台tps --> 170,另外一台 --> 130,排除这个问题。

    网络瓶颈或者容器设置问题？？不太会，网络延时并不大，而且如果是这两样的话不应该前后的响应时间差别太大（测试时间10分钟），猜测是某个java容器随着压力慢慢到了资源极限，可能是cpu，也可能是mem，磁盘不太会毕竟容器跟磁盘交互还是比较少的。另提一点，压力测试中，小包为主考虑网络间的发送接受能力（类似于磁盘的iops，需要考虑长连接问题，网络延时问题，可以简单的用ab [-k] -n  -c 测试），如果以大包为主考虑带宽问题，当然部分机器还有网卡问题，记得DELL R720的网卡，redhat 5.4系统，流量一大网卡就会出问题，还要打补丁，唉，压力测试前网络和硬件测试还是很必要的。

    top命令监控所有java容器的主机，之前研发说系统压力没问题的，结果发现一个java进程cpu 330%，还有几个java是100%左右，这也叫系统压力没问题啊，我擦，问题的容器再加一个节点（nginx配置转发），tps --> 600,问题发现了，还是容器的问题，优化代码或者堆机器加节点吧。

    最后并发轻松到了1000，松了口气，再解决不了就打算tcpdump抓包分析了（这种方法很容易能发现事务各个节点的处理能力问题，当然如果研发能把测试脚本分开测试更直观，-个事务分割成n个，分别测试），同事很高兴的立即去跟领导回报说自己已经解决了系统压力问题，我也是醉了，跟我又没关系了，关机回家吧。

    案例很简单，测力能力有限，只是记录一下自己的思路，希望对别人有帮助，能够及时发现问题。

建议：

    （1）非专业人员测试的话（比如研发），最好能找来系统和数据库工程师一起看看，集思广益么

    （2）一开始就应该从系统压力入手，监控单个进程  top -p xxx 更有效（既能看到整体压力，又能看到单个进程的占用资源），io的话 iostat -xk xx xx基本就够了，当然习惯用nmon或者htop看个人了

    （3）如果是网络或者容器配置问题，测试中各个阶段性能变化应该不大

 转帖：美乐家