性能测试时总会有一堆数据摆在面前却不知道如何分析,特别是对于新人对来说性能测试可能是个比较新的概念,只有理解了每个性能指标的含义才能让我们更好的去分析结果。
最近在做服务端的性能压测,整理了一些常用的基本性能指标,具体如下。
比较容易理解,其实就是运行程序占用的CPU资源,程序的运行会不断的有线程起来让CPU来处理,CPU对线程的响应是非连续的,如果未响应的线程数增加,那么CPU使用率就会飙高。当usr+sys使用率超过80%,我们就认为基本达到瓶颈。
说到CPU不的不提的是load的概念,load是对CPU使用率很好的考量。load的小取决于系统cpu核心数,比如双核CPU表示load到达2便是满负荷运行,load大于2时表示已经超负荷。
针对Linux系统来说,我们可以很方便的通过命令查看load情况,linux系统每隔5秒钟进行一次数据采样,下面是load查看情况:
load averages后面有3个数据:
a.第一个0.00表示最近1分钟平均负载
b.第二个0.01表示最近5分钟平均负载
c.第三个0.05表示最近15分钟平均负载
哨兵系统中你看到的load1、load5、load15便是上面所说的三个数据。
通常我们看在看服务端load性能指标时,首先需要看load15情况,如果load15飙高,再看1分钟和5分钟load,验证是否有下降趋势。当前服务端物理机性能大大提高,CPU一般不会是瓶颈,项目组这边机器一般都是32核,当load不超过20一般不去关注。
内存大家应该都比较清楚,测试过程中我们需要关注内存变化情况,内存变化一般都比较明显,如果有内存泄漏可以很清晰的看出。主要关注内存使用率的变化情况,公司哨兵系统可以方便的查看变化情况。
我们也可以通过执行命令的方式查看实际内存使用情况:
从应用层的角度来看,buffer/cached是为了提高文件读取的性能,当应用程序需在用到内存的时候,buffer/cached会很快地被回收,所以对于应用程序来说,可用内存为free+cached+buffer。我们需要关注内存使用情况时需要特别关注下这点。
网卡通常关注网卡流量,现在一般服务器都是万兆网卡,但我们测试环境大多数还是千兆网卡,所以在测试过程中这个指标需要多关注下,很容易成为我们测试的瓶颈,这些指标信息都可以通过公司哨兵系统查到数据。
磁盘一般需要我们查看磁盘使用空间,是否已经达到阈值上限。同时我们还需要关注磁盘I/O情况,这些数据都可以从哨兵系统中很直观的看到,无非就是util不要过高,I/O不超过50%。
并发量是从业务角度来表示的性能指标,并发分两种一种是纯粹的并发,严格意义上的并发,比如Get一个对象,同时有10个同样的Get操作表示10个并发量。另一种是从业务实际使用角度来看广义范围上的并发,比如用户使用服务时不仅有get还有put以及Head等操作,那么同一时刻10个不同的请求,同样表示10个并发量。我们在测试过程中应该尽量模拟第二种使用情况,这样能够更好的对系统进行评估。
用户并发量也是评估系统性能的一个重要指标,随着并发数的增加,系统的压力会逐渐加大,达到一定的系统瓶颈,表示系统能够承受的最大并发量。以此我们可以根据线上实际并发情况,来不断调整后端服务系统的负载。
TPS/QPS简单说就是系统的吞吐量,但两者还是有区别的。
TPS/QPS通常是作为衡量服务端处理能力的重要指标。
响应时间一般是指某一端到另一端发起请求到响应结束之间的时间。
通常我们只关心客户端这边的响应时间:客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不得不等待的时间长度。
不同的服务对于响应时间的要求不一样,国外有个3/5/10原则:
当然这也不是标准,如果上层服务能够承受底层服务响应慢,那也是可以接受的。测试中如果客户端响应时间过长,需要我们进一步分析后端服务之间响应时间,进而缩小范围确定瓶颈。
哨兵中我们会看到有连接状态统计的一项,这同样是我们关注的重点,TCP的各种连接状态多达11种,但个人觉得需要重点关注以下几种即可:ESTABLISHED、CLOSE_WAIT、TIME_WAIT。测试过程中我们可以关注下这几个指标是否有异常,比如大量TIME_WAIT、CLOSE_WAIT,且我们需要关注整体ESTABLISHED数量。
在实际测试中,我们如何评估系统的性能指标,没有一个标准,我们在测试时可以多进行下数据对比,和老版本的服务进行对比,或者和其他环境数据进行对比。比如最近在公有云压测,我们这边会拿公有云压测结果和当前私有云线上实际情况进行对比,验证下是否能够承受住类似私有云的压力。
以上便是整理的一些常用的性能指标,上面讲到的都是服务端一些基本的简单易理解的指标,还有很多需要我们去深入了解,比如数据库相关指标、Jvm监控相关的指标,欢迎大家总结分享。
本文来自网易实践者社区,经作者刘成授权分布。