jmeter教程（二十）：性能测试执行及结果分析

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

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

现在，启一个线程让这个脚本一直循环运行，查看运行情况，因为是循环运行，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个线程跑。