简介
JMeter 是 apache 开发的基于 java 的压力测试工具。可用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能，另 jmeter 可以使用它做性能的图形分析或在大并发负载测试服务器/脚本/对象。
作用
- 能够对HTTP和FTP服务器进行压力和性能测试，也可以对任何数据库进行同样的测试（通过JDBC）
- 完全的可移植性和100% 纯java。
- 完全多线程 框架允许通过多个线程并发取样和通过单独的线程组对不同的功能同时取样。
- 精心的 GUI 设计允许快速操作和更精确的计时。
- 缓存和离线分析/回放测试结果。
高扩展性
- 可链接的取样器允许无限制的测试能力。
- 各种负载统计表和可链接的计时器可供选择。
- 数据分析和可视化插件提供了很好的可扩展性以及个性化。
- 具有提供动态输入到测试的功能（包括Javascript）。
- 支持脚本编程的取样器（在1.9.2及以上版本支持BeanShell）。
下载与安装
因为 JMeter 依赖于 JDK 环境，所以需要先安装 JDK, 安装 JDK 的文章很多，网上可以很容易的找到，这里不再赘述。
- 官网 DOWNLOAD 目录下，可下最新版本
- 下载后可以解压到你喜欢的位置，其启动脚本在 /apache-jmeter-5.4.1/bin 下
- 对于mac，到 /apache-jmeter-5.4.1/bin 下，双击 jmeter 文件（或者 sh jmeter），即可启动
- 也可通过配置环境变量，用命令启动
正常启动之后可以看到如下界面，默认为英文，不过你可以在菜单栏中 【Options】-> 【Choose Language】下选择合适的语言。
常用组件介绍
线程组
为了模拟一下多用户并发测试的情况，需要通过配置线程组来配置所需要的并发信息，在 Test Plan 右击，可以看到 Add，选择添加线程组即可。（Test Plan 是默认的名字，如果你修改了，名称会变）
添加之后如图
各个配置的含义
**Name：**任意，可以写一个简单易懂的名字
**Comments：**备注信息
Action to be taken after a Sampler error (采样器错误后要采取的措施)
- Contiune：继续。某一个请求遇到错误后，其他请求继续执行。我们在大量用户并发的时候，某个请求失败属正常现象。当线程组内没有相互依赖的测试操作时，可以配置。
- Start Next Thread Loop：如遇到错误后面的请求将不再执行，等下一轮再开始执行。例如线程组中包含登录和发帖 2 个请求，若登录请求失败，发帖请求将不再执行，等下一次重新迭代，从登录开始执行。当线程组内有必须相互依赖的测试操作时，可以配置。
- Stop Thread：遇到错误就停止线程再也不执行了。例如线程组中有 50 个线程，其中某一个线程的某个请求遇到错误即停止线程不再执行，剩下 49 个线程继续执行。若线程错误的比较多，剩余的线程就较少，此时负载数量就不足了，测试结果不满足测试要求，因此一般不会勾选此项。
- Stop Test：某个线程某个请求遇到错误，停止所有线程，也就是停止整个测试，但是线程中的余下的请求还是会执行完再停止。例如线程1中包含登录和发帖2个请求，其他线程遇到错误，现在要全部停下来，线程1发帖请求还是会执行，然后再停止测试。
- Stop Test Now：遇到错误立即停止所有线程，即整个测试。
一般常用的为 Contiune 和 Start Next Thread Loop
Thread Properties 中的配置，是我们最关心的，也是这里的配置最重要的部分。
- **Number of Threads(users) ：**线程数，一个线程相当于一个虚拟用户
- Ramp-Up Period(in second)： 告诉 Jmeter 需要花费多久的时间启动全部的线程，单位秒。即所有线程在多长时间内全部启动。例如线程60个，Ramp-Up Period设置为 20s，那么每秒启动 60(个) / 20(秒) = 3（个/秒） 线程，不填写默认设置为0，即所有线程在开启场景后立即启动。该配置可以用来模拟用户逐渐增多的情况，比如因为限流的原因，某系统可能在 3 分钟后才会切分到 100%流量，最大流量是 1000，那就可以配置线程数是 1000，Ramp UP 是 180
- **Loop Count：**循环次数。
- 勾选 Infinite: 将一直执行，除非手动停止或崩溃，或者通过配合下面的 Duration 来组合使用，达到一定时间的持续测试。
- 不勾选 Infinite，手动输入次数，则总共将线程组测试循环 3 次。
Delay Thread creation until needed: 延时创建线程直到该线程需要采样时。勾选，例如50个线程Ramp-Up Period为10s，那么每隔1s启动50/10=5个线程并运行下面的请求（状态为running）；不勾选，测试计划开始后启动所有线程（状态为new），但是不立即执行下面的请求。例如50个线程Ramp-Up Period为10s，那么计划开始后所有线程全部就绪，但第一秒只有5个线程开始运行请求。实际应用中选择哪种都可以，不影响测试结果。
Same user on each iteration: 在 JMeter 中，user 就是线程，此选项的意思是说每个迭代都用相同的线程。在以前 3.x 和 4.x 版本的 JMeter 中，是没有这个选项的。创建好 1 个线程后，每次迭代都是用这个线程，直到测试结束。它的影响就是，比如登录，加了 HTTP Cookie 管理器以后，单个线程多次迭代（注意不是多个线程哦）登录用的都是相同的 Cookie。
5.x 版本加入了这个选项，可以控制每次迭代是否创建新的线程。同时在 HTTP Cookie 管理器也增加了一个选项，控制是否清除旧 Cookie. **默认这个 Same user on each iteration 的选项是勾选的。**因为销毁和创建线程本身就会占用资源，可能会影响性能测试结果。
Specify Thread lifetime
- Duration：持续时间，单位秒。Loop Count 勾选了 Infinite，才有作用。可以用其控制整个测试的持续时间
- Startup delay：启动延迟，单位秒。延迟到时间后再运行线程。
为什么我接口都是毫秒级的，吞吐量才 30
前几天，一个好友问我，为什么我接口响应都是毫秒级的（10ms 以内），但是用 JMeter 进行压测，吞吐量才 30。当时想想，你这接口响应时间肯定超过 100ms 了，不然就算一个线程进行压测 10ms 内响应时间，不会是 30，至少应该 100 呀！
于是她发了测试的结果，然后我和她要了响应的时间图
从测试结果看确实才 30/s，而且 99% 以内的请求都在 7 毫秒就完成，95%的请求在 4 毫秒就完成了。显然根据经验，4 毫秒的响应，一个线程持续压测，也能得到 1（秒）/ 0.004 (秒) = 250 （次/秒），也不可能是 30，于是测试让朋友去优化代码，提高性能。
但单纯的根据响应时间来看，其实并不需要进行优化，于是她发来了测试的线程组配置如下图：
从图中的配置可以看出，线程数为 500，Ramp Up 为 50s, 循环次数为 3，错误操作为继续。
从可以配置可以看出，总请求次数为 500（线程数）* 3（循环次数）= 1500 次，Ramp Up 为 50s, 也就是线程数从 0 到 500 全部投入工作需要 50s（并不是 50s 之前没有线程在工作，是达到 500 个线程同时工作至少需要 50s 开始）
先跳出一下，看看吞吐率的定义：
吞吐率: 单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。
但是从业务的角度看，吞吐率也可以用“业务数/小时”、“访问人数/小时”、“页面访问量/小时”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。
因为在测试 HTTP 请求，这里使用单位时间内处理客户请求数量。从上面的线程组的配置中，假设请求响应的时间忽略不计的情况下（按 0 算），则测试执行的总时间为 50（秒），请求的总次数为 500（线程数）* 3（循环次数）= 1500 次，按照定义的计算方式为 1500（次）/ 50 (秒) = 30（次/秒），也就是说就算测试一个 0 纳秒的接口，得出的吞吐率也是 30（只能小于等于 30）。
通过这个实际例子，可以看出，不合理的线程组配置，会导致不合理的结果。
一般配置
在测试中，一般都需要进行长时间的压测才能得到一个比较准确的结果，一般在压测时，我是这样进行配置的。
Ramp Up 设置 10，既模拟用户 10s 内可以就绪
Loop Count 勾选 Infinite
Duration 设置 180s，如果测试时间充裕，可以设置 600s，也就是 10 分钟
线程数 分别使用 50、100、150、200、250、300、350、400 进行多轮测试，通过多轮测试来得出应用在不同情况下的表现（当然这样测试时间会长一点，但是效果会好一点）
