JMeter聚合报告和性能分析思路

JMeter请求参数解释

• Number of Threads(users)：线程数（即并发数）；一个用户占一个线程，200个线程就是模拟200个用户；
• Ramp-Up Period(in seconds)：设置线程需要多长时间全部启动；如果线程数为200，准备时长为10，那么需要1秒钟启动20个线程；也就是每秒钟启动20个线程；
• Loop Count：并发执行次数，一次场景下来，请求的数量=线程数 * 循环次数；如果线程数为200，循环次数为10 ，那么每个线程发送10次请求；总请求数为200*10=2000 ；如果勾选了“永远”，那么所有线程会一直发送请求，直到选择停止运行脚本；

---

JMeter聚合报告参数解释

• Label：每个JMeter的element的Name值，例如HTTP Request的Name；
• Samples：发出请求数量；模拟20个用户，循环100次，所以显示了2000；
• Average：平均响应时间（单位：ms）；默认是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间；
• Median：50%的用户响应时间小于这个值；
• 90%Line：90%的用户响应时间小于这个值；
• 95%LIne：95%的用户响应时间小于这个值；
• 99%LIne：99%的用户响应时间小于这个值；
• Min：用户响应时间最小值；
• Max：用户响应时间最大值；
• Eorror%：测试出现的错误请求数量百分比；请求的错误率 = 错误请求的数量/请求的总数；若出现错误就要看服务端的日志查找定位原因；
• Throughput：简称TPS，吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，TPS越高说明服务器处理能力越好；
• KB/sec：每秒从服务器端接收到的数据量；

---

压测结果分析

• Error%：确认是否允许错误的发生或者错误率允许在多大的范围内；
• Throughput：吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
• 最大的TPS：不断的增加并发数，加到TPS达到一定值开始出现下降，那么那个值就是最大的TPS；
• 最大的并发数：最大的并发数和最大的TPS是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数；
• 压测的时候要时刻关注应用服务器数据库服务器等CPU、内存、网络等使用情况；
• 压测过程出现性能瓶颈，若压测客户端任务管理器查看到的CPU、网络和CPU都正常，未达到90%以上，则可以说明服务器有问题，压测客户端没有问题；
• 影响性能考虑点包括：数据库、应用程序、中间件（php-fpm、nginx、redis…）、网络和操作系统等方面；

---

性能测试关注点

• 客户端响应时间是否满足要求
• 服务器资源使用情况是否合理
• 应用服务器和数据库资源使用是否合理
• 最大访问数，最大业务处理量是多少
• 系统可能存在的瓶颈在哪里
• 能否支持7*24小时的业务访问
• 架构和数据库设计是否合理
• 内存和现成资源是否可以被正常回收
• 如果系统出现不稳定情况，其可恢复性如何

---

一些常识

• CPU、TPS存在明显波动则存在瓶颈
• 并发时服务日志级别需调整为error级别
• 通常请求由一个线程负责执行，占用一个逻辑CPU
• 若并发量增加而CPU使用率未增加则存在瓶颈
• CPU负荷、内存负荷集中在应用服务器和数据库服务器上 （CPU是负责运算和处理的，内存是交换数据的）
• 磁盘负荷集中在数据库/文件服务器上
• 对外网络流量集中在负载均衡器（nginx、LVS）上

---

性能分析思路

对于一个软件而言，用户最终关心的是响应时间对于他们的长短，因此把响应时间作为分析的起点。在整个处理过程中，可以把响应时间分为：呈现时间（浏览器解析）+数据传输时间（带宽，网络瓶颈）+系统处理时间（数据库+服务器，系统瓶颈）；

• 呈现时间根据用户使用的浏览器及用户本身的硬件关系比较大，不可控，所以忽略；
• 再来看网络时间，JMeter工具得到的时间是Tn+Ts，使用最贱的ping获取网络时间，分析得出是否是网络瓶颈；
• 再看服务器时间，是应用服务器的问题还是数据库服务器的问题；

总结

一般情况下，当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间 得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的 响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。