做性能测试，先是根据策略编写脚本，然后才是执行脚本，现在我已经编写好了脚本，一个最简单的脚本。

然后保存，运行，在察看结果树里，可以看到正确的响应结果。

现在，启一个线程让这个脚本一直循环运行，查看运行情况，因为是循环运行，HTTP请求，会执行很多次，而这些结果都在察看结果树里显示出来，就不是很好，所以在察看结果里里勾上，只显示错误的请求信息。

然后线程组配置成永远循环，调度器设置成60秒，我这里只是演示，就不去跑10分钟了。

配置好保存，清除之前的结果，之后就开始运行。

右上角，小框框里面显示的是脚本的运行时间，小三角形前面的数字，代表jmeter运行过程中的异常数，这个异常数和脚本里的错误是两码事。比如连接不上服务器，这里就会有异常。小圈圈前的0/1代表当前正在运行的线程数和脚本运行中的最大线程数，因为现在脚本已经停止运行了，所以没有线程在运行，所以前面就是0。而且我的脚本运行时，只启了一个线程，所以最大线程数就是1。在察看结果树里，没有结果输出，代表没有错误的请求，重点看聚合报告。

Label：是请求的名称。
#Samples：在脚本运行过程中，一共发了多少个请求。
Average：平均响应时间，服务器处理一个请求需要多少时间的平均值，单位：毫秒。
Median：响应时间的中间值，就是所有请求的响应时间从小到大排个序，正中间的那个值是多少。
90%Line：响应时间从小到大排序，在第90%位置处的值是多少，比如一共发了10000个请求，那么就是第9000个的值。
95%Line、99%Line同上。
Min：最小响应时间，就是所有请求中响应时间最短的那一个。
Max：最大响应时间，就是所有请求中响应时间最长的那一个。
Error %：错误率，错误请求占所有请求的比率是多少。
Throughput：这个就是常说的TPS了，也就是中文常说的吞吐量。代表的是服务处理请求的能力，服务器在1秒之内能处理多少个请求。
最后面两个就是每秒接收数据量和发送数据量，不过这两个值，有些情况下会没有。

因为跑的时间比较短，再跑长点时间，TPS可以到1000。因为我这个框架，业务比较简单，而且数据库里的数据也非常少，所以响应非常快。通过响应时间，我们可以推算出服务器一个线程，在1秒内可以处理多少个请求。比如这里是1毫秒，那么服务器一个线程，1秒是可以处理1000个请求的。不过呢，这个1毫秒是向下取整得来的，显示是1毫秒，而实际上可能是1.2或是1.3毫秒。再通过TPS，就可以推出服务器大致启了多少个线程在处理请求。比如平均响应时间是20毫秒，那么服务器一个线程一秒可以处理50个请求，如果TPS是400，那么就可以推出服务器大概是启了8个线程在处理请求。当然，这个并不是绝对的，尤其是在服务器没有达到极限的时候。接下来，再看服务器的资源使用情况。

可以看到，在刚开始发请求的时候，服务器的CPU使用率非常地高，最高的时候达到了75%，因为这个时候，服务器要创建很多线程，线程又要处理业务，所以CPU的使用率就变得很高了。然后，到了后期，线程都创建好了，那么就只有处理业务的消耗，所以CPU的使用率就慢慢的降下来了，并趋于平稳。内存就没有什么可看的了，跑得时间短，如果跑的时间比较长，比如10分钟，而在跑的过程中，一直在增高，那么就要考虑有内存泄露的问题了。而磁盘I/O，因为没有打日志，所以就完全没有了。

1个线程的跑完了，服务器的性能就有了一个基准值。那么就要再加线程跑，现在加到2个线程跑。

清除之前的结果，运行。

可以看到2个线程的时候，TPS是1677，相较于1个线程的TPS，没有达到2倍，存在着衰减，当然跑的时间太短，对比的数据，参考性不是很准确。然后，再启3个线程跑：

2个线程TPS是1677，3个线程是1729，只增加了一点点。那么就可以得出结论，服务器的TPS极限就是1700多一点。后面，再增加线程来压，TPS也增长不动，甚至还会出现下降的情况。

现在只是测试了一种情况，还有带参数的情况，只是脚本改一下，测试的过程是差不多的。再然后就是做参数化，让脚本在运行的过程中，不停地改变参数，来查看服务器的的性能，新建一个记事本，内容如下：

然后，在脚本里引入这个文件，读取里面的内容做参数。

然后线程组，设置启一个线程，循环4次，察看结果树的只显示错误，不勾选，运行一下，看结果。

可以看到，4次，每次运行的结果都不一样，然后就是让脚本一直循环，持续运行一段时间，看性能数据。

这是启2个线程跑的，可以看到，比之前全是一样的请求时，性能下降了。

  这是我整理的《2024最新jmeter接口测试和jmeter接口自动化测试全套教程附带性能测试》，以及配套的接口文档/项目实战【网盘资源】，需要的朋友可以下方视频的置顶评论获取。肯定会给你带来帮助和方向。