行业动态

性能测试常见指标分析

  什么是性能测试?

  压力测试:强调极端暴力

  稳定性测试:在一定压力下,长时间运行的情况

  基准测试:在特定条件下的性能测试

  负载测试:不同负载下的表现

  容量测试:最优容量

  外部指标

  从外部看,性能测试主要关注如下三个指标

  吞吐量:每秒钟系统能够处理的请求数、任务数。

  响应时间:服务处理一个请求或一个任务的耗时。

  错误率:一批请求中结果出错的请求所占比例。

  响应时间的指标取决于具体的服务。如智能提示一类的服务,返回的数据有效周期短(用户多输入一个字母就需要重新请求),对实时性要求比较高,响应时间的上限一般在100ms以内。而导航一类的服务,由于返回结果的使用周期比较长(整个导航过程中),响应时间的上限一般在2-5s。

  对于响应时间的统计,应从均值、.90、.99、分布等多个角度统计,而不仅仅是给出均值。下图是响应时间统计的一个例子

  

性能测试常见指标分析

  吞吐量的指标受到响应时间、服务器软硬件配置、网络状态等多方面因素影响。

  吞吐量越大,响应时间越长。

  服务器硬件配置越高,吞吐量越大。

  网络越差,吞吐量越小。

  在低吞吐量下的响应时间的均值、分布比较稳定,不会产生太大的波动。

  在高吞吐量下,响应时间会随着吞吐量的增长而增长,增长的趋势可能是线性的,也可能接近指数的。当吞吐量接近系统的峰值时,响应时间会出现激增。

  错误率和服务的具体实现有关。通常情况下,由于网络超时等外部原因造成的错误比例不应超过5%%,由于服务本身导致的错误率不应超过1% 。

  一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。

  单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。

  系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

  QPS(TPS):每秒钟request/事务 数量

  并发数: 系统同时处理的request/事务数

  响应时间: 一般取平均响应时间

  (很多人经常会把并发数和TPS理解混淆)

  理解了上面三个要素的意义之后,就能推算出它们之间的关系:

  QPS(TPS)= 并发数/平均响应时间

  一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

  决定系统响应时间要素

  我们做项目要排计划,可以多人同时并发做多项任务,也可以一个人或者多个人串行工作,始终会有一条关键路径,这条路径就是项目的工期。

  系统一次调用的响应时间跟项目计划一样,也有一条关键路径,这个关键路径是就是系统影响时间;

  关键路径是有CPU运算、IO、外部系统响应等等组成。

  我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

  而通常境况下,我们面对需求,我们评估出来的出来QPS、并发数之外,还有另外一个维度:日PV。

  通过观察系统的访问日志发现,在用户量很大的情况下,各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

  通常的技术方法:

  1. 找出系统的最高TPS和日PV,这两个要素有相对比较稳定的关系(除了放假、季节性因素影响之外)

  2. 通过压力测试或者经验预估,得出最高TPS,然后跟进1的关系,计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样,这两个客户群的网络行为不应用,他们之间的TPS和PV关系比例也不一样。

  从服务器的角度看,性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等

  CPU

  后台服务的所有指令和数据处理都是由CPU负责,服务对CPU的利用率对服务的性能起着决定性的作用。

  Linux系统的CPU主要有如下几个维度的统计数据

  us:用户态使用的cpu时间百分比

  sy:系统态使用的cpu时间百分比

  ni:用做nice加权的进程分配的用户态cpu时间百分比

  id:空闲的cpu时间百分比

  wa:cpu等待IO完成时间百分比

  hi:硬中断消耗时间百分比

  si:软中断消耗时间百分比

  us & sy:大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的,us的比例高了,sy的比例就低,反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁,此时系统整体性能会有一定下降。另外,在使用多核CPU的服务器上,CPU 0负责CPU各核间的调度,CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。

  ni:每个Linux进程都有个优先级,优先级高的进程有优先执行的权利,这个叫做pri。进程除了优先级外,还有个优先级的修正值。这个修正值就叫做进程的nice值。一般来说,被测服务和服务器整体的ni值不会很高。如果测试过程中ni的值比较高,需要从服务器Linux系统配置、被测服务运行参数查找原因

  id:线上服务运行过程中,需要保留一定的id冗余来应对突发的流量激增。在性能测试过程中,如果id一直很低,吞吐量上不去,需要检查被测服务线程/进程配置、服务器系统配置等。

  wa:磁盘、网络等IO操作会导致CPU的wa指标提高。通常情况下,网络IO占用的wa资源不会很高,而频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务,那需要检查被测服务的日志量、数据载入频率等。

  hi & si:硬中断是外设对CPU的中断,即外围硬件发给CPU或者内存的异步信号就是硬中断信号;软中断由软件本身发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断,也就是我们常说的系统调用(System Call)。在性能测试过程中,hi会有一定的CPU占用率,但不会太高。对于IO密集型的服务,si的CPU占用率会高一些。

  常见性能瓶颈

  吞吐量到上限时系统负载未到阈值:一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况,可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因

  CPU的us和sy不高,但wa很高:如果被测服务是磁盘IO密集型型服务,wa高属于正常现象。但如果不是此类服务,最可能导致wa高的原因有两个,一是服务对磁盘读写的业务逻辑有问题,读写频率过高,写入数据量过大,如不合理的数据载入策略、log过多等,都有可能导致这种问题。二是服务器内存不足,服务在swap分区不停的换入换出。

  同一请求的响应时间忽大忽小:在正常吞吐量下发生此问题,可能的原因有两方面,一是服务对资源的加锁逻辑有问题,导致处理某些请求过程中花了大量的时间等待资源解锁;二是Linux本身分配给服务的资源有限,某些请求需要等待其他请求释放资源后才能继续执行。

  内存持续上涨:在吞吐量固定的前提下,如果内存持续上涨,那么很有可能是被测服务存在明显的内存泄漏,需要使用valgrind等内存检查工具进行定位。

        以上是关于软件测试的知识,由多测师亲自撰写,全网独家提供!  https://www.duoceshi.com/

新闻资讯

联系我们

联系人:何女士

手机:13825291265

电话:0755-21072941

邮箱:hr@duoceshi.com

地址: 广东省深圳市龙华区龙华街道清湖和平路62号优鼎企创园D栋201室,202室

用手机扫描二维码关闭
二维码