cpu性可以测试(性可以测试常用指标分析)

压力测试:对极端暴力的压力。稳定性试验:在建议压力下，长时间运行。基准测试:特定条件下的性可以测试。负载测试:不同负载下的性可以容量测试。最佳容量。

外部指标

对外，性可以测试主要关注以下三个指标

吞吐量:系统每秒可以够处理的请求和任务的数量。

响应时间:服务处理请求或任务所需时间。

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

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

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

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

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

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

网络越差，吞吐量越小。

在低吞吐量下，响应时间的平均值和分布相对稳定，不会引起太大的波动。

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

错误率与服务的具体实现有关。一般情况下，网络超时等外部原因造成的错误比例不超过5%%，服务本身造成的错误率不超过1%。

系统的吞咽可以力与请求、外部接口、IO等CPU消耗密切相关。

单个reqeust的CPU消耗越高，外部系统接口和IO的冲击速度越慢，系统的吞吐量越低，反之亦然。

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

QPS(TPS):每秒请求//事务的数量

并发性:系统同时处理的请求//事务的数量。

响应时间:一般榷冉均响应时间。

(许多人经常混淆并发性和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的利用率对服务的性可以起着决定性的用处。

Linux系统的CPU主要有以下维度的统计数据

Us:在用户模式下使用的cpu时间百分比

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

ni:nice-weighted进程分配的用户状态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或内存的异步信号是硬中断信号；软中断软件本身发送给操作系统内核的中断信号。通常是硬中断处理程序或者进程调度程序对操作系统内核的中断，也就是我们常说的系统调用。性可以测试时，hi会有建议的CPU利用率，但不会太高。对于IO密集型服务，si的CPU利用率会更高。

常见的性可以瓶颈

当吞吐量达到上限时，系统负载没有达到阈值:一般是被测服务分配的系统资源太少造成的。如果在测试过程中发现这种情况，可以够从ulimit的维度、系统打开的线程数量、分配的内存来定位问题的原因。

CPU的us和sy不高，但wa高:如果测试的服务是磁盘IO密集型的，wa高是正常的。但是，如果不是这种服务，wa高最有可可以的原因有两个。第一，服务读写磁盘的业务逻辑有问题，读写频率太高，写的数据太多，比如数据加载策略不合理，日志太多，都可可以导致这个问题。第二，服务器内存不足，服务在交换分区不断换进换出。

同一请求的响应时间波动很大:这个问题发生在正常吞吐量下。有两个可可以的原因。一是服务对资源的加锁逻辑有问题，导致在处理一些请求的过程中，有大量时间等待资源解锁；第二，Linux本身分配给服务的资源有限，有些请求需要等待其他请求释放资源后才可以继续执行。

内存持续上升:在吞吐量固定的前提下，如果内存持续上升，很可可以是测试的服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。