性能压测场景
1、本次需要对查询接口进行100、200、500并发逐渐递增方式进行性能压测
2、在压测过程中，100、200并发响应时间、吞吐量、报错率为0，满足性能需求
3、当并发用户为500时，报错率达到22%，此时经过监控服务器，发现服务器cpu、内存、硬盘、网络、应用服务gc情况未出现异常，满足指标
4、经过排查，本次应用服务使用的是Dubbo服务，通过修改jmeter断言，返回响应结果提示threadpool is exhausted ,detail msg:Thread pool is EXHAUSTED!，通过检查dubbo服务配置，threads只有200，当线程数大于200，就会报系统繁忙，请稍后在试，将该设置改为1000，500并发压测未出现报错，满足性能需求
5、本文记录下优化前测试结果、监控服务器(linux)资源方法、优化方法、优化后测试结果
一、优化前测试结果
- 100并发测试结果
- 200并发测试结果
- 500并发测试结果
二、服务器资源监控
- 网络资源情况：可以使用 sar -n DEV 10 120 命令，10代表10秒执行一次，总共执行120次，由下图可见 rxkB/s：每秒钟接收数据量，单位kb， txkB/s：每秒钟发送数据量，单位kb ，每秒接收和发送没超过6M每秒，可以使用ifconfig命令查看网卡名称，然后使用ethtool eth0 查看当前服务器的带宽配置，由截图可知，当前网速带宽万M，每秒传输可达1000多M每秒，使用率不到1%，6M不考虑网络瓶颈
- 硬盘读写情况：可以使用iostat -x k 1 5命令，1代表1秒执行一次，总共执行5次，由图可知，总共有5块磁盘，磁盘最大读取900kb/S，最大写入2.2M/S，目前磁盘读取写入速度都是100M以上了，2M不考虑磁盘瓶颈，也可以关注%util指标，%util 表示磁盘忙碌情况，一般该值超过80%表示该磁盘可能处于繁忙状态
- cpu负载情况：可以使用uptime命令，while true; do uptime; sleep 60; done 该命令能持续执行uptime命令，每隔1分钟执行一次，显示最近1、5、15分钟cpu负载情况，由下图可知，负载量最高为5，该服务器cpu核心数为4(上面硬盘、网络命令均有显示4CPU)，如果超过4*1.7=6.8，考虑负载过高，sar - u 10 120，该命令用来查看所有cpu的使用率，由下图可知user+system的cpu使用率75%，未超过90%，不考虑CPU处理瓶颈，也可以使用 sar -P 0 1 2命令跟踪具体的cpu， 该命令0代表第一块CPU
- 内存使用情况 ：使用free命令即可下图的while true; do free; sleep 10; done为每10秒执行一次，由图可见8G内存只使用了2.1G，可被应用程序使用的物理内存还有4.4G，不考虑内存瓶颈
- 应用服务(java类型)监听：首先输入jps -l ，该命令是显示当前系统所有的java进程，最前面显示的是进程id，找到当前应用服务的进程id，输入jstat -gcutil 29033 10000 29033代表进程id，10000代表10秒输出一次，该命令是跟踪java进程内存使用情况，由图可知FGC(主要关注该参数，代表回收老年代，每次回收应用都需要等待)总共发生了6次，压测期间没有增加，FGCT是FGC耗时24秒，如果频繁fgc考虑调整该服务内存大小，该服务进程内存满足需求
- 下图使用nmon进行监控，推荐使用该开源工具，./nmon -f -s5 -c10代表每隔5秒采集一次，采集10次，该工具可以监控到cpu、内存、硬盘、网络各种指标
三、优化方法
- 第二章监控了服务器的cpu、硬盘、内存、网络都满足性能要求，未出现异常，最后通过查看测试结果输出的HTML报告，看到系统返回报错的响应结果中提示duboo服务线程已经耗尽，最大线程数数为200
-
经过查看dubbo服务器配置，发现配置的线程数只有200，修改线程数为1000，在执行性能压测，结果满足指标，修改指标参考下图
- 参考地址 http://www.voidcn.com/article/p-bmgbfqvq-brm.html
四、优化后的测试结果
- 500并发测试结果如下：未出现异常
- 执行日志
五、性能瓶颈调优层级
如果文章对你有帮助，欢迎关注本人公众号，公众号与本平台文章同步，方便大家查阅，本人会持续推出与测试有关的文章，与大家分享测试技术，每一篇原创文章都是用心编写，杜绝抄袭复制
QQ技术交流群：加群请输入验证信息 51cto
微信二维码关注公众号：
关注之后，回复资源下载，即可获取本人共享的各种资源下载地：
