这一次,我来说下性能测试中的性能指标。
性能指标有许多项,真正的性能测试也分很多种类,如负载测试,压力测试,稳定性测试等。但对于我们程序员来说,需要清晰无误的理解的指标主要是以下一些指标:
本周,继续写给程序员的JMeter教程,这是第二篇,本系列其它文章为:
同样是性能测试,不同人群的关注点并不一样。比如客户是希望通过性能数据以得知购买的软件或服务的承载能力及扩展成本,测试团队做性能测试关注于保证软件或服务的正确性。
那程序员对于性能测试,关注点在哪?
这个问题留到文章最后我再来说下我的想法。
Thread
线程数,这是一个与请求数有关联的指标。
实际使用中,不同的用户会在不同的地方或使用不同的设备来访问我们的服务,每一个用户都在使用我们的软件或服务的过程会产生许多请求数。
对于性能测试,我们没有办法模拟真实的不同用户,不同地点或不同设备来访问我们的服务,我们只能通过一种方式:线程。
通过同时并发的产生多个线程,每个线程去请求与访问我们在性能脚本中设定好的流程,以达到模拟用户请求的场景。
在JMeter中,你不只可以设置线程数,还可以设置它在多少时间内产生,循环多少次等。
注意
性能测试,不仅与服务的性能承载能力有关,本身压测机器的性能也有关联。做Java后端开发的,都知道系统能同时承载的线程数是有限的,那理所当然,压测机的同时能产生的线程数也是有限的。
如果压测机性能不够怎么办?
大家可以先思考下,后面的文章我会讲到这个。
TPS(每秒事务数)
事务这个词,对于程序员来说,最熟悉的可能是数据库事务。性能测试的事务,指的其实是一个业务过程。
怎么才算一个业务过程?
这其实是由你在Jmeter中定义的,默认一个组件,比如一个HTTP请求,就会产生一个事务。
当然,这并不是绝对的,你可以把一系列的行为归集到一起,当成一个事务来对待。这样的操作在JMeter中也是支持的。
那TPS(每秒事务数)的意思就很容易理解了:每秒钟能处理多少个这样的业务
那当然,每秒处理的越多,代表着性能越高。
注意
但这并不是绝对的,没有正确率的保障,TPS再高也豪无意义。
KO
我在JMeter报告中第一次看到这个,有点不太理解它的意思,后面才发现,它是OK的反写。
OK是指正确的,那很容易理解KO就是错误的。
KO是指发生错误的请求。
那你可能想知道在性能测试中,如何才算是错误的?
你可以先思考下,后面的文章我会继续说到这些,怎么在性能测试中去识别正确与错误。
Average/Min/Max(平均/最小/最大响应时间)
响应时间,分别表示平均,最小以及最大。
这个指标应该很好理解,就是当前事务的平均响应,最小响应以及最大响应需要多久。
这三个指标,最需要关注的可能是平均响应时间。
90th pct/95th pct/99th pct
这三个指标,其实还是指的响应时间。
只不过它表示的是90%请求的最大响应时间,95的请求的最大响应时间以及99%的请求的最大响应时间。
简单点讲就是:90%的请求,都会在这个时间值内被处理完毕。
互联网上不是有个说法: 一个网站3秒内没有响应,用户就会离开,可能现在的用户3秒都无法忍受了。
那同样,你的服务在多少时间内能响应,这个指标非常有价值。
CPU/内存使用
这个指标其实在JMeter中不会出现,因为JMeter是客户端行为,对于服务器的CPU及内存使用其实是并不知情的。
所以一般我们会用nmon搭配来做性能测试,在被压测的服务器上部署nmon来收集服务器在测试过程中的CPU/内存使用情况。
当然,我认为对于程序员来说,除非你要出具相关的数据报告,不然不一定需要做到这个程度,在Linux服务器上,直接使用top去观察CPU,内存使用情况就好了。
比如,我在对myddd-vertx微服务架构做分布式部署的测试中,就发现最大的阻碍在于Mysql数据库,它的CPU达到了245%,而其它服务都没有到100%,这说明整个系统的性能阻碍在于数据库。
这些我都是通过top命令就直观察觉到的。
好了,回到最开始的问题,程序员做性能测试,我们到底是在关注什么东西?
我个人认为,以下这些都是程序员的关注点:
所以,程序员关注点用一个词来形容,就是:
代码的正确性
好,理解了这些指标后,我们可以开始我们的第一步了。就是下载与安装一个JMeter。
当然,这个其实是非常简单的。
下一篇文章,我还会简单说下JMeter与LoadRunner的差异与对比,因为当说到性能测试时,我们可能不能不说到LoadRunner。
下一篇,写给程序员的JMeter教程(二):JMeter的安装及与LoadRunner的对比