使用Apache JMeter开展商业Web应用负载测试需关注的性能指标问询

一、核心响应类指标 #

• 响应时间（Response Time）：从用户发请求到收到完整响应的总时长，涵盖网络传输和服务器处理时间。要分开看单接口请求响应时间和业务事务响应时间（比如下单、支付这类多接口组成的完整流程），确认高负载下是否在业务允许的阈值内。
• 百分位响应时间（Percentile Response Time）：比如P90、P95、P99，意思是90%、95%、99%的请求响应时间都不超过这个数值。比起平均响应时间，这个指标更能反映大部分用户的真实体验，不会被个别极端值带偏。
• 响应时间波动幅度：负载变化时响应时间的起伏程度，如果波动太大，说明应用在负载变化时稳定性不够。

二、吞吐量与并发类指标 #

• 吞吐量（Throughput）：单位时间内服务器处理的请求或事务数量，常用单位是“请求/秒”或“事务/分钟”。高负载下吞吐量能不能稳定在预期值，是衡量应用处理能力的核心。
• 每秒点击数（Hits per Second）：单位时间内服务器收到的HTTP请求总数（包括图片、CSS这类静态资源请求），能体现Web应用的资源承载压力，尤其适合静态资源多的场景。
• 并发用户数：同时和服务器建立连接、发起请求的用户数量。要关注JMeter模拟的虚拟用户数和服务器实际的并发连接数，验证应用在目标并发量下的稳定性。
• 事务通过率：成功完成的事务数占总事务数的比例，直接反映业务流程能不能正常跑起来，高负载下通过率得保持在100%或者业务允许的极低错误率范围内。

三、服务器资源利用率指标 #

这些指标需要配合JMeter的监控插件（比如PerfMon）来收集，主要看服务器会不会成为性能瓶颈：

• CPU利用率：服务器CPU的使用占比，如果持续超过80%，很可能导致响应时间暴涨，得排查是不是有计算密集型任务或者线程卡住了。
• 内存使用率：包括JVM堆内存和系统内存的占用情况，如果内存使用率持续上升，大概率是存在内存泄漏，最后可能引发OutOfMemoryError。
• 磁盘I/O：磁盘的读写速率、队列长度，高负载下磁盘I/O过高，可能是数据库查询慢、日志写得太频繁导致的。
• 网络带宽：服务器的进出网络流量，如果带宽跑满了，请求延迟会明显增加，得确认能不能扛住业务峰值的流量需求。
• 数据库核心指标：比如数据库CPU使用率、连接数、查询响应时间、锁等待时间，很多Web应用的性能瓶颈其实出在数据库层。

四、错误与稳定性指标 #

• 错误率：失败请求数占总请求数的比例，包括HTTP状态码错误（4xx、5xx）和业务逻辑错误（比如返回了错误的订单数据）。高负载下错误率必须严格控制，一旦超过阈值，就说明应用稳定性出问题了。
• 错误类型分布：区分清楚是服务器内部错误（5xx，比如503服务不可用）、客户端错误（4xx，比如404资源找不到）还是超时错误，能快速定位问题根源。
• 超时率：请求超时的比例，超时一般意味着服务器没法及时处理请求，是稳定性下降的明显信号。
• 线程/连接池状态：应用服务器的线程池、数据库连接池的使用情况，如果一直处于满负荷状态，要么是资源配置不够，要么是连接没及时释放。

五、用户体验相关指标 #

• 页面加载时间：完整加载一个页面（包括所有静态资源）的时间，模拟真实用户打开页面的体验，一般得控制在2-5秒内才符合用户预期。
• 首次字节时间（TTFB）：从发请求到收到服务器第一个字节的时间，反映服务器的响应速度和网络延迟，如果TTFB太高，说明服务器处理初始请求的速度慢。

内容的提问来源于stack exchange，提问作者Chamindra Sulakshith