关于cpu性能测试（性能测试常见指标分析） 的知识大家了解吗？以下就是小编整理的关于cpu性能测试（性能测试常见指标分析） 的介绍，希望可以给到大家一些参考，一起来了解下吧！
cpu性能测试(性能测试常用指标分析)
压力测试:压力极端暴力稳定性测试:在一定压力下，长时间跑步；基准测试:特定条件下的性能测试；负载测试:不同负载下的性能& n优优资源网bsp容量测试:更佳容量
(资料图片仅供参考)
外部指标
对外，性能测试主要关注以下三个指标
吞吐量:系统每秒可以处理的请求和任务的数量。
响应时间:服务处理请求或任务所需的时间。
错误率:错误结果的请求在一批请求中所占的比例。
响应时间的指标取决于具体的服务。智能提示等业务，返回数据有效期短(用户多输入一个字母需要重新请求)，实时性要求比较高，响应时间上限一般在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的关系，计算出系统日吞吐量更高的Yoyo资源 *** 。B2B和 *** 面对的客户群体不同。这两个客户群体的 *** 行为是不适用的，他们之间的TPS和PV关系所占的比例也是不同的。
从服务器的角度来说，性能测试主要集中在CPU、内存、服务器负载、 *** 、磁盘IO等方面。
中央处理器
服务后台的所有指令和数据处理都由CPU处理，服务对CPU的利用率对服务的性能起着决定性的作用。
Linux系统的CPU主要有以下维度的统计数据
Us:用户使用c尤优资源 *** pu时间的百分比。
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等内存检查工具进行定位。
