后台性能测试不可不知的二三事

作者：TMQ Apollo
某月黑风高之夜，某打车平台上线了一大波（G+）优惠活动，意在约饭、约酒、约P的众人纷纷下单。于是乎，该打车平台使用的智能提示服务扛不住直接趴窝了（如下图）。事后，负责智能提示服务开发和运维的有关部门开会后决定：必须对智能提示服务进行一次全面深入的性能摸底，立刻！现在！马上！

那么一大坨问题就迎面而来：对于智能提示这样的后台服务，性能测试过程中应该关心那些指标？这些指标代表什么含义？这些指标的通过标准是什么？下面将为您一一解答。

概述

不同人群关注的性能指标各有侧重。后台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者不仅仅关注外部指标，还会关注CPU、内存、负载等内部指标

拿某打车平台来说，它所关心的是智能提示的外部指标能不能抗住因大波优惠所导致的流量激增。而对于智能提示服务的开发、运维、测试人员，不仅仅关注外部指标，还会关注CPU、内存、IO等内部指标，以及部署方式、服务器软硬件配置等运维相关事项。

外部指标

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

• 吞吐量：每秒钟系统能够处理的请求数、任务数。
• 响应时间：服务处理一个请求或一个任务的耗时。
• 错误率：一批请求中结果出错的请求所占比例。

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

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

• 吞吐量越大，响应时间越长。
• 服务器硬件配置越高，吞吐量越大。
• 网络越差，吞吐量越小。

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

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

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

内部指标

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

CPU

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

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

• us：用户态使用的cpu时间百分比
• sy：系统态使用的cpu时间百分比
• ni：用做nice加权的进程分配的用户态cpu时间百分比
• id：空闲的cpu时间百分比
• wa：cpu等待IO完成时间百分比
• hi：硬中断消耗时间百分比
• si：软中断消耗时间百分比

下图是线上开放平台转发服务某台服务器上top命令的输出，下面以这个服务为例对CPU各项指标进行说明

• us & sy：大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的，us的比例高了，sy的比例就低，反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降。另外，在使用多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。
• ni：每个Linux进程都有个优先级，优先级高的进程有优先执行的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。一般来说࿰