关于性能测试总结-Jmeter

关于性能测试总结-Jmeter

关于面试经常提问的有关性能测试问题:
1、TPS压不上去，可能有哪些方面原因？
2、性能测试过程中，怎么判断网络瓶颈？
3、性能测试过程中遇到过什么解决，你是怎么解决的？
…

下面为大家讲解一下本人做性能测试的一些总结和遇到的问题，个人觉得性能测试跟使用的工具无关，主要是测试思想，使用的工具能满足思想即可，比如最近阿里推出的性能平台PTS（Performance
Testing
Service）一分钟发起压力测试，采用的思想就是比较简单易上手，https://help.aliyun.com/document_detail/70290.html?spm=5176.7946858.1368709.6.f6fc2542FI5fI9；地址附上有兴趣可以了解一下，不过PTS为收费平台，且比较适用于电商平台这种全链路压测场景，所以大部分性能测试用jmeter就能搞定，好了废话不多说了，开始总结吧！

一、性能测试需要关注指标和配置？
测试指标：吞吐量、TPS、平均响应时间，其中通过TPS就能大概分析出性能指标，只是大概而已，具体问题具体分析。其中 JMeterPlugins插件能监控详细曲线图。
服务器指标：CPU(top或atop)、内存(free -m)、磁盘I/O(df -h)、network I/O(nmon工具) 等
服务配置相关：服务器配置(比如4核16G)；节点数(每个服务起几个)、服务内存(服务启动内存)、数据库缓存内存(关注缓存内存满时)、服务最大连接数(连接数通过压测中不断配置，过大过小都不行)

二、详细说明
性能测试需要关注很多指标，以上列举的也只是一部分，那么这些如何用？如何监控呢？首先我觉得需要一个详细的步骤来分析：
1、首先准备测试相关工具，需要jmeter安装Plugins插件
添加Ultimate Thread Group线程组(该线程组可实现阶梯型压测，目的为服务器预热准备)，添加插件中TPS(Transactions per Second)监控和平均响应时间监控(Response Times Over Time)；【具体脚本设计请查看jmeter脚本总结文章】
2、了解服务器和服务相关指标
（1）查看CPU信息：cat /proc/cpuinfo | grep name 注：几行就是几核
（2）查看内存信息：cat /proc/meminfo | head -4 注：总数除以1024在除以1024为几G
（3）查看已启动服务：ps -aux | grep java ,可查看启动的所有java服务，包括该服务启动的内存、进程号、jar包所放路径、端口号等，可进入jar包中查看服务配置的最大连接数，比如vim jars/xxx/xxx_端口.jar，进入后/筛选（不同的部署方式查看不同）
（4）查看部署后剩余内存 free -h，关注：available可用内存，这里推荐一个工具finalshell 与Xshell类似，但是左侧有CPU和内存占比，也可查看每个路径下使用内存大小
（5）查看磁盘占用情况，df -h，可查看磁盘使用比例
（6）关注数据库缓存内存，由于缓存内存有最大值，当达到最大值时缓存机制会自动释放，所以压测过程中开始内存下降会较为严重，当缓存内存最大值后，内存才不会明显下降，此时关注剩余内存，如果压测一段时间后内存依然下降严重，则考虑内存溢出问题
（7）CPU关注：重点关注，可使用yum安装atop(详解：http://www.361way.com/atop/5162.html)，CPU关注各服务百分比，如果使用finalshell 可点击左侧“进程管理”，监控各服务占比；4核CPU最大400%，每一核最高100%；
*
三、正题
关于第一个问题：
1、TPS压不上去，可能有哪些方面原因？
答：首先关注硬件资源CPU、内存、磁盘IO，CPU是否过高、内存是否不足、磁盘空间是否不足；如果硬件资源充足则关注网络宽带(单位时间内数据包过大，超过传输能力，一般接口响应数据多大超多1M[100并发就是上百M]则关注该指标，使用nmon监控)；如果都不是则调整服务连接数和数据库连接数，比如100连接数调整成500等等；调整后依然压不上去，则关注该接口的业务处理，是否存在大量查询和update，写入数据sql是否增加索引，关注是否主从分离或读写分离，大量的查询和更新导致数据库事务处理过慢是影响TPS的重要条件；且同步排查压测脚本，是否参数未进行参数化，同一参数大量传值造成锁表现象，修改压测脚本全部使用参数化传参；最终辅助排查条件还可通过分布式压测(单机负载能力有限)，采用分布式压测关注系统指标变化，或通过扩容关注指标变化；
各项工作完成后可讨论业务逻辑和系统架构，比如业务较为复杂，事务线被拉过长，系统缓存服务配置和缓存命中率等

2、性能测试过程中，怎么判断网络瓶颈？
答：首先TPS压不上去，平均响应时间很慢，此时关注吞吐量，如果吞吐量多大会占用大量宽带资源，导致后续虚拟用户无法得到服务器资源；可优化建议：a、降低页面的请求次数 b、优化页面中各个元素的容量大小 c、多方面结合缓存机制
注：服务器的出口带宽很低时会导致QPS很低，调整扩大出口宽带： https://www.cnblogs.com/alisapan/p/11497385.html
查看服务器的出口带宽：ethtool eth0；前面是命令，后面跟的是设备名，如果对外连接的网络设备是eth1，那就需要改成：ethtool eth0
3、性能测试过程中遇到过什么解决，你是怎么解决的？
问题一：性能测试时查看响应时间曲线图偶尔出现超时，但是大部分平均响应时间并不高，查看日志和各项指标都很正常，最终排查后定位到日志打印问题，修改日志等级为error后问题解决，还可以将日志改为异步日志。
问题二、压测开始报错，或压测开始响应时间过长，停止压测后重新压测正常；采用阶梯式压测，并发逐渐上升，给服务器预热时间
问题三：频繁压测很长一段时间都正常，突然一次压测开始报错，而且每次都会报错，排查磁盘使用较多，删除日志回复磁盘空间后解决
问题四：压测过程中响应时间经常一段时间出现过高，排查硬件资源均正常，查看日志分析出现sql慢查导致，优化sql后正常
问题五：稳定性压测，持续压测5小时后出现大量报错，报错比例一直增加，且部分响应时间达到几十秒，经排查发现一个java进程的CPU使用率很高，使用jvm查看内存回收情况，发现有大量不能回收存在，最终定位到内存溢出
问题六：压测观察TPS曲线图忽高忽低，偶尔会到0，查看服务器日志发现连接池不足，加大连接池后问题解决
问题七：TPS开始半分钟较高但是过了半分钟直线下降始终压不上去，查看各项指标正常，排查日志发现该业务会频繁update导致数据库锁表，后代码改成异步+队列处理，tps恢复正常

Android7系统以上配置系统证书：https://blog.csdn.net/Aaron_Miller/article/details/106992121?utm_medium=distribute.pc_relevant_bbs_down.none-task–2_allfirst_rank_v2_{rank_v29-3.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task–2}all_{first_rank_v2}rank_v29-3.nonecase