在实际的生产运行、测试过程中，一般都会关注吞吐量、响应时间、CPU利用率，在开发和测试阶段，我们不但需要关注，而且要通过它们之间的关系来验证测试的结果是否可信、分析性能问题在哪里。
吞吐量和响应时间的关系
这里先举一个例子，通过计算，发现测试结果不可信的例子。
该场景是服务器并发处理业务报文，并且达到了最大处理能力(即TPS达到最大，如果再增加压力，就出现拥堵现象)，性能测试结果如下：
看了之后结果，我立刻说：不可能
原因如下：这个场景中TPS=14，一共有20个进程并发处理。那么每个进程每秒钟处理的业务个数=14/20=0.7个。
那么每个业务的响应时间(理论计算)=1(秒)/0.7=1.43秒。
而测试结果显示，业务响应时间为240毫秒(0.24秒)，这中间的1.42-0.24秒哪里去了?这个结果一定不可信。随即，我咨询对于响应时间的统计方式。得到的答复是：统计工具从日志里面统计的。好吧，只能打开原始日志看了。
原始日志中每个业务有5个时间戳，我姑且叫它们ABCDE吧。
A：客户端发起的时间(按照客户端的机器时间给打的时间戳)
B：服务器端进程从消息中间件中取出消息的时间
C：服务器端开始处理的时间
D：进程认为自己处理结束的时间
E：写这一条日志的时间
当前的统计方式是D-C。
问：为什么不是E-B?
答：开发人员说按照D-C
好吧，不扯那么多了，计算吧。
计算几万条业务的E-B的平均时间，1573.34毫秒，和我们理论的计算(1.43秒)基本吻合。
所以，之前的统计方法是错误的。
和CPU利用率的关系
举第二个例子，和CPU利用率相关的例子。
这个例子中，同样是服务器并发处理某类业务报文，性能测试结果如下：
平均响应时间是198.78毫秒，即0.19878秒。那么每个进程每秒钟处理的业务个数=1/0.19878=5个。
服务器一共设置了最大20个进程并发处理。那么如果这20个进程都被调用起来全速处理的话，它们的最大处理能力是每秒钟=20*5=100个。
而当前的TPS=52.46，相当于最大能力(100)的52.46%，那么CPU利用率也应该差不多这个数，我们实测的CPU利用率是56%，考虑随着TPS的增加，业务响应时间也是会变化的，系统的CPU也不是完全线性变化的，上述的计算推测已经是非常吻合实际情况了。说明这个测试当中，各个系统性能数据之间是可以从数字关系上对上号，说明他们的取值都是正确的。
这里还要多说一点，在虚拟化环境下，大多数人对AIX/Power系统的CPU利用率取值是错误的，因此拿起测试结果大致一算，是对CPU利用率取值的快速验证。虚拟化环境下Power系统的CPU利用率取值我在之前的文章中有过介绍，感兴趣的同学可以回看。
杨建旭，师从中国工程院院士陈纯教授，于2006年获得浙江大学计算机学院硕士学位，曾获得授权发明专利10余项、SCI/EI索引论文8篇。现任中国人民银行清算总中心性能测试团队负责人，高级技术经理。曾就职于VIA(中国)、VMware(中国)，对虚拟化趋势下银行业系统的性能测试、问题分析、性能调优有丰富的经验。
扩展阅读：
CPU利用率异常的分析思路和方法QA——虚拟化相关
(一) PowerVM环境下的CPU监控和分析与物理机环境有哪些差异?
首先：利用率的概念不同。
虚拟化环境下CPU利用率相对于EC(标称计算能力)来说，可以超过100%。
相对于VP(虚拟CPU)来说，永远是<=100%。
相对于运行时获得的物理CPU来说，永远是<=100%。
CPU利用率的统计方法：
若physical CPU没有超过EC，则采集EC利用率。
当Physical CPU<=EC时，EC利用率=(EC_User% + EC_Sys%)/EC值。
Nmon CPU_ALL Sheet：CPU%
或Nmon LPAR Sheet：EC_User% + EC_Sys%
若physical CPU超过EC：
此时若按照EC利用率统计，则CPU利用率很可能超过了100%，出具的测试结果、测试报告容易造成误解。
此时若按照physical CPU利用率(使用的CPU/physical CPU)统计，分母physical CPU是动态的，因此利用率不具有参考价值。
如果一定要统计CPU利用率，可按照VP利用率统计，VP利用率= VP_User% + VP_Sys%。但需要假设CPU物理Core的个数为VP个数。举例说明：
假设EC=2，VP=8，EC利用率为200%，VP利用率为50%。在测试报告中描述CPU利用率为50%(CPU为8核，其中EC为2C，借用为借用资源池)。
第二：虚拟化环境关注的参数更多，这些参数会对性能产生巨大的影响。
虚拟化环境需同时关注以下参数：
CPU核数
标称计算能力(Entitled Capacity，简称EC)
虚拟CPU(Virtual CPU，简称VP)
逻辑CPU个数(Logical CPU)
SMT
有上限/无上限(Capped/Uncapped)
型号/时钟频率
处理器折叠(Processor Folding)
运行时物理CPU(Physical CPU)
(二) 开发的应用在CPU核数一样的虚拟服务器上性能表现出较大的差异
1、用的是什么虚拟服务器?VMware还是PowerVM的?还是其他的平台?
2、假如是VMware，用的是ESX/vSphere还是VMware Workstation，二者架构不同，性能不同，PC上的VMware Workstation不是裸金属模式，性能不好。
3、虚拟机上看到的核数，可能不是真正的核数。比如说VMware上，看到的2个core，其实是x86 CPU的一个core中的一个超线程。
如果这个x86 CPU一个core是两个线程，那么虚拟机中的两个core只相当于物理的一个core。当然，这是能够完全抢占的情况下。如果没有完全抢占，那就更小了。
如果是PowerVM的虚拟机，操作系统看到的核数是VP(虚拟CPU)，至于这个LPAR运行时候，能得到多少物理CPU以及这些物理CPU的亲和性，可能差异很大。
(三) 虚拟化下CPU核数超分配有没有最佳实践
问题：在虚拟化的环境下，一般可以超分配CPU核数。一般会有一个临界值。过了这个值CPU性能就大幅下滑。我们如何找这个值，有没有什么最佳实践?
所谓的“最佳实践”其实是厂商给出通用值，具体到你的单位头上，并不一定是最佳的。世界上没有所谓的通用的最佳。就好比，两地三中心、异地双活之类的设计方案，没有什么最佳实践，每个企业都有根据自己的特点来设计。
回到你的问题，如果你的系统追求最短的响应时间(核心交易系统)，VP和EC的比值越小越好。如果，追求最大瞬时CPU获得，设置大一些更好，最大可以是10，适用于平时没有什么业务量的非核心系统。
(四) EC高低似乎对业务响应时间没什么影响，为什么?
问题1：
解答1：
这个是需要运气的。
是否做上下文切换，取决于进程是不是每次被调用到同一个VP上，VP是不是每次被调用到同一个物理CPU上。
如果你的资源池，资源比较充足，那么hypervisor按照亲和性调度，你的VP每次得到的物理CPU是一样的，所以响应时间不受影响
反之，资源紧张，多个LPAR争抢，亲和性大打折扣，响应时间就起伏很大。
亲和性的数值，可以通过下面方式查询
Nmon的BBBP sheet
命令行Mpstat –d
问题2：
"那么如果要看运气的话，物理资源多少才算闲置，总利用率多少需要开始关注CPU亲和度了，需要开始着手处理此类问题了"
解答2：
首先要理解亲和度的概念，是CPU是否能从cache1、2、3里面读到数据。举个例子，有1000个进程跑在一个CPU上，但都是不怎么干活的进程，一会儿进程A上来占用，一会进程B上来占用，但总体CPU利用率并不高，但每个进程上来后都要有自己的进程上下文。可能此时cache1、2、3根本缓存不了这么多上下文。结果就是大量的上下文切换。
因此不会有一个绝对的指标，说物理资源多少才开始关注CPU亲和度。
针对 “物理机的整体CPU利用率究竟达到多少时，需要考虑扩大LPAR的EC”
是否扩大LPAR的EC，主要考虑的是你的业务需求是否能够得到满足(例如，响应时间是否满足要求，吞吐量是否跟得上)，而不是主要考虑物理机的整体CPU利用率。
