性能测试系列（一）

什么是性能测试？
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

如何来做性能测试
在这里插入图片描述

通常来说，性能测试考虑这么几个因素：Thoughput吞吐量，Latency响应时间，资源利用（CPU/MEM/IO/带宽…），成功率，系统稳定性等
首先根据系统运营情况，设定单机系统期望的响应时间，建议TP99，以及成功率。比如金融类：99.9%响应时间在10ms以内，成功率99.999%
在相应时间和成功率限制下，逐步提供并发量来寻找最高吞吐量
在第二步找到的最高吞吐量基础上，进行稳定性测试，n*12小时不间断压测。收集系统的CPU、MEM（java应用建议收集JVM内存）、磁盘/网联IO等指标，来评测系统是否稳定，CPU、MEM曲线是否平稳
寻找系统的极限值，继续提高并发量，不考虑响应时间，成功率99.999%下，寻找系统能够承受10分钟以上的极限值
用第二步的值66%做为系统的软告警阈值；80%作为硬告警阈值(单机性能)；而第四步的极限值作为突发

流量考虑

java项目中性能测试常见的问题如何排查
施压端负载并发再高，但是就是TPS就是压不上去，cpu、mem也较低?
1）快速排除施压端的问题

可以另外再起一个施压端，TPS还是上不去，基本可以排除施压端问题，集中精力看被压服务端
长短连接问题，是否keep alive
2）cpu使用率低，那io如何，io包括磁盘io、网络io等
结合linux自身的top、vmstat、iostat逐步排查
3）网络带宽如何
可以借助iftop等确认
很多时候，我们才知道性能的问题，比如：带宽不够，内存不够，TCP缓冲区不够，等等，不需要调整程序的，只需要调整一下硬件或操作系统的配置就可以了
4) 如果cpu不高、IO不高、Mem也不高、带宽也不高，就是TPS上不去，此时可以排查自身服务应用问题了
jstack pid连续3次以上当前时刻的线程快照，确认过热线程的行为
服务自身的线程池是否需要调高
cpu使用率低，但是负载较高?

产生原因：等待I/O完成的线程过多，但是cpu运行的线程却很少
什么是负载：负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息，也就是cpu使用队列的长度统计信息，这个数字越小越好（如果超过CPU核数*0.7就是不正常）
常见问题
- 磁盘读写请求过多就会导致大量I/O等待，可以通过vmstat命令去确认
- MySQL中存在没有索引的语句或存在死锁等情况,MySQL中运行show full processlist命令查看线程等待情况，把其中的语句拿出来进行优化
  cpu使用率过高?
  如果是java应用可以采取如下步骤
  1）先使用【ps aux |grep +关键字】查找进程ID
  2）再使用【top –H –p +进程ID】取得线程pid

使用命令【 printf “%x\n”+ pid】将10进制的线程id换成16进制Tid
*4）然后jstack （第一步中的ID） | grep 16进制Tid *查看具体的进程堆栈信息，找到具体问题代码行数信息
内存溢出?
问题表现

生产运行一段时间后程序出现假死，或者高峰时间段程序响应较慢，大量请求超时
日志中出现java.lang.OutOfMemoryError: Java heap space ，java.lang.OutOfMemoryError: PermGen space
gc日志里superuser@t1-test-003:/app/log/upay-gateway$ grep -i full gc.log
2018-09-24T16:35:26.392+0800: 6861.093: Full GC (System.gc()) 2037M->86M(4096M), 0.7044486 secs
2018-09-24T16:39:09.051+0800: 7083.752: Full GC (System.gc()) 1861M->82M(4096M), 0.6773289 secs

常见原因

内存分配过小，与实际业务需要空间不符。
对象频繁被创建，却没有被释放，导致内存泄漏。
有限系统资源（线程、网络连接）被不断的申请，导致系统资源被耗尽。

问题排查
内存分配过小确认, jmap -heap PID 进行查看确认
在这里插入图片描述

如果确实小了，可以根据情况增大jvm内存设置，比如启动参数里-Xms16g -Xmx16g -XX:+UseG1GC
借助jvm 工具,比如jstat来查看gc状况
在这里插入图片描述

YGC：年轻代gc次数
YGCT：年轻代gc所用时间(s)
FGC：old代gc次数
FGCT：old代gc所用时间(s)
从上图可以看出，FGC次数较多，并且时间较长
抓取java进程jvm信息，jmap -dump:format=b,file=文件名 pid
借助可视化工具，比如jvisualvm来分析dump信息

性能测试系列（一）

猜你喜欢