Jmeter压测思路+实操+报告分析

RBI强调了80%的性能问题可以通过吞吐量测试来发现，其他20%的性能问题可以通过引入并发用户数等更复杂的场景来发现。

执行方案
核心思路： 性能测试中不只关注并发数，尤其是单接口性能测试的时候，更多关注吞吐量、响应时间等指标来评估服务端性能。验证服务端最高每秒能正确处理的请求数，以及请求的响应延时情况。
首先明确下并发的概念。在性能测试中并发可以理解为同一时刻做不同的事，或同一时刻做同样的事。一般我们在性能测试的时候也是这么去模拟的。那这个同一时刻的并发是很难做到的。要知道我们用来发起压力的测试工具本身要能做到同一时刻发起压力，如果设置线程数过多，负载机本身资源不足会有排队，请求建立和服务端的连接过程会排队，请求数据发送到服务的时候在网络队列上也会排队，请求数据达到服务端，在服务端也会进行排队，所以严格意义上的并发多少用户数等等是比较难做到的。
为什么要压测
这个问题问的其实挺没有必要的，做开发的同学应该都很清楚，压测的必要性，压力测试主要目的就是让我们在上线前能够了解到我们系统的承载能力，和当前、未来系统压力的提升情况，能够评估出当前系统的承载情况能不能满足当前和未来一段时间的正常运行。压力测试也让架构师和开发人员能够对自己负责的系统做到心中有数，当有大并发需求的活动或者其他突发事件导致的访问暴增，能够提前做好预估和准备应急预案。

压测难点
说了那么多，都是压测的必要性，那么既然要测那么重要，我们每次发版本都做一下压测不就好了，这么说的同学一定是没真正参与过压测的，参与过压测的同学都是谈压测色变，不管是测试人员还是开发人员都很害怕压测。大家为什么这么害怕压测，主要原因主要有下面这些压测的难点导致的：

1）压测环境难准备

在日常工作过程中，我们肯定遇到过压测环境难申请的问题，为什么难申请主要是因为压测一般要求环境和生产环境一致，那么就意味着压测机器资源的稀缺，没有哪家公司会长期准备所有系统的压测环境，毕竟成本太高，所以一般公司都是准备一些机器让所有系统共用压测环境，每次一个系统要做压测之前都要把上一个压测系统的数据和应用版本、中间件、数据库停掉或删掉，这是非常浪费时间的工作，所以很多公司现在在压测的环境准备都使用docker来准备环境，只需要定期更新docker image就可以，这就可以做到快速还原环境，需要用的时候直接把被测系统的docker image拉下来就行了，所以压测环境已经不再是我们的问题了。

2）压测数据难准备

在压测过程中还有个难点就是压测数据准备，如何能尽量真实的模拟生产的数据，最简单的就是录制一段时间生产的访问报文，然后在用压测环境进行正常回放和倍数回放。录制生产真实报文的工作，目前还没有遇到特别好的工具，大部分公司都是自己写个工具进行网络层面的嗅探，将嗅探到的生产报文再加工成Jmeter或者LoadRunner这些压测工具能