JMeter聚合报告里的中位数、90%百分位和吞吐量，分别代表了用户感知的响应速度和系统整体的处理容量。

中位数是请求响应时间排序后位于正中间的那个数值，描述的是典型用户感受到的快慢，因为排除了极端值的影响，所以比平均响应时间更稳定地反映大多数请求的表现。

90%百分位则是排序后第90个百分点的响应时间，意味着只有十分之一的请求比这个数值更慢，这个标准专门用来暴露性能的长尾问题，即那些响应明显偏慢的少数请求，对于发现系统短板非常敏感。

吞吐量则是单位时间内系统成功处理的请求数量，一般以每秒请求数计，它直接体现了系统的承载能力和处理效率。

这三个标准之间存在着紧密的动态关联。一般情况下，响应时间越短（中位数和90%百分位越低），系统在单位时间内能完成的请求就越多，吞吐量自然越高；反之，如果响应时间普遍增长，吞吐量就会相应下降。但这种反比关系并不是绝对的，因为吞吐量还受到并发用户数、系统资源利用率和短板步骤的影响。比如，当系统达到饱和时，即便响应时间大幅上升，吞吐量也可能不再增加甚至下降，这时三个标准会同向恶化。因此，仅凭任何一个单一标准都无法全面评价系统性能，必须结合来看。

在实际分析中，这三个标准能帮助我们快速定位问题类型。假设测试结果中中位数较低但90%百分位很高，说明大多数请求很快，但总有少数请求异常慢，这往往指向数据库查询、缓存未命中或外部接口超时等偶发问题。如果中位数和90%百分位都偏高，而吞吐量偏低，则说明系统整体处理能力不足，可能是硬件资源、代码效率或网络带宽存在普遍短板。如果吞吐量较高但90%百分位也较高，则意味着系统虽然能扛住压力，但用户体验并不一致，存在性能抖动，需要优化那些偶尔变慢的步骤。

在性能测试中应该把90%百分位作为重视对象，因为它直接关系到绝大多数用户的上限体验。同时解读响应时间时一定要参考当时的吞吐量水平，因为只有在相同吞吐量下比较响应时间才有意义。一般我们会固定吞吐量目的，然后观察中位数和90%百分位是不是满足服务等级协议，或者固定响应时间要求，然后不断加压看吞吐量能达到多少。合理的性能目的应该同时包含对百分位数（如95%的请求在200毫秒内完成）和吞吐量（如系统必须支持每秒500个请求）的确定约束，这样才能既保证用户体验又满足容量需求。

中位数、90%百分位和吞吐量共同刻画了系统在不同负载下的行为曲线。在低负载时，三者都会表现良好；随着负载增加，一般先是中位数和90%百分位缓慢上升，吞吐量线性增长；继续加压，90%百分位会率先急剧恶化，随后中位数也开始上升，最后吞吐量达到峰值后不再增长甚至下降。通过监测这三个标准随负载的变化趋势就能准确判断系统的性能拐点和容量极限，为容量规划和优化提供依据。