在实际的生产运行、测试过程中，一般都会关注吞吐量、响应时间、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也不是完全线性变化的，上述的计算推测已经是非常吻合实际情况了。说明这个测试当中，各个系统性能数据之间是可以从数字关系上对上号，说明他们的取值都是正确的。
如有任何问题，可点击文末阅读原文到社区原文下评论交流
扩展阅读：
CPU利用率异常的分析思路和方法QA
（问题诊断思路）
Q：CPU利用率上不去
A：CPU有两头怕
1）怕CPU占用率高
2）怕CPU占用率低
重点解释一下为什么怕CPU低。有时候，业务压力冲上来了，但都被挡在外面，或者堆在队列了，而此时看CPU利用率却很低，也就是有CPU但没有用上。
这种情况有好多原因，这里说几个原因
1）并发线程数太少
并发数应该开多少呢？ 假如你的应用线程是全力干活的线程，没有什么SLEEP、等IO之类的事情，也就是说，一个线程可以把一个物理CPU THREAD吃的满满的。那么你的最大并发线程，可以设为略小于服务器的逻辑CPU数量。也就是CPU CORE SMT。如果你是虚拟化POWERVM环境，逻辑CPU=VPSMT，但虚拟化环境，需要额外注意，如果你要保持高性能，那么建议略小于EC*SMT即可。
2）虚拟化平台的参数配置有问题
比如某个LPAR，EC=0.5，VP=5，那么很可能，压力来了之后，CPU利用率也上不去，报文严重堆积。因为可能系统环境中物理机的CPU占用率已经较高，各个LPAR之间借用CPU已经非常严重，大部分时间都花在hypervisor的调度上，以及CPU的cache命中失败去内存找数据取了。
关于这方面的原理，可以参考文章：
性能指标之资源指标 CPU亲和性原理介绍及如何量化读数
http://www.talkwithtrend.com/Article/160881
3）其他各类参数限制导致应用能力被约束，尤其以数据库为甚
比如应用连接Oracle数据库服务器的JDBC连接数太少，数据库的process太少等等，导致应用在等待数据库。如果单从数据库来讲，以Oracle为例，可以看看AWR的top等待事件。
比如logswitch等待时间长，可能需要调整redo日志组数和日志大小
比如索引等待时间长，可能需要调整为索引分区
比如rego日志sync等待时间长，可能需要调整存储的能力。
4）应用逻辑设计问题
逻辑设计复杂，流转过程长，导致不能很好的并发利用资源。
可以类比CPU流水原理，CPU设计为什么设置多级流水，而不是一级流水把一个指令执行完。
Q：主机资源使用繁忙，到底是因应用需要做优化处理还是确实物理资源不足导致？
A：1、CPU资源不足，首先可以考虑优化。优化首先考虑技术层面优化
2、如果技术优化无果，则进入业务优化。更改业务流程，业务处理方式。例如：
a) 实时检查，改为定期检查
b) 每秒钟检查一次，改为每分钟检查一次
c) 实时清算改为定时清算
3、如果业务优化仍然无果，则需要加资源，甚至从总体上更改架构。毕竟任何CPU、任何服务器、任何系统都是有业务上限的。
Q：CPU利用率居高不下的原因有哪些？
A：1、绝大多数情况是应用写的烂
算法差，或者无意的应用调用，触发了内核函数占用CPU高。
这里所说的应用包括中间件、数据库（比如SQL写的差，没做变量绑定（硬解析），索引设置不合理，数据库物理设计不合理等等）。
2、参数类
系统参数（比如缓存什么情况下往硬盘刷，设置不得当，刷的频率太快）
编译参数（各种优化选项，以及各种依赖关系）
数据库参数（比如可以共享游标去节省CPU消耗，但却没有做）
中间件参数（比如GC策略）
CPU利用率异常的分析思路和方法QA
（虚拟化相关）
Q：PowerVM环境下的CPU监控和分析与物理机环境有哪些差异？
A：首先：利用率的概念不同。
虚拟化环境下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）
A：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性能就大幅下滑。我们如何找这个值，有没有什么最佳实践？
A：所谓的“最佳实践”其实是厂商给出通用值，具体到你的单位头上，并不一定是最佳的。世界上没有所谓的通用的最佳。就好比，两地三中心、异地双活之类的设计方案，没有什么最佳实践，每个企业都有根据自己的特点来设计。
回到你的问题，如果你的系统追求最短的响应时间（核心交易系统），VP和EC的比值越小越好。如果，追求最大瞬时CPU获得，设置大一些更好，最大可以是10，适用于平时没有什么业务量的非核心系统。
问题描述1：
A1：
这个是需要运气的。
是否做上下文切换，取决于进程是不是每次被调用到同一个VP上，VP是不是每次被调用到同一个物理CPU上。
如果你的资源池，资源比较充足，那么hypervisor按照亲和性调度，你的VP每次得到的物理CPU是一样的，所以响应时间不受影响
反之，资源紧张，多个LPAR争抢，亲和性大打折扣，响应时间就起伏很大。
亲和性的数值，可以通过下面方式查询
Nmon的BBBP sheet
命令行Mpstat –d
问题描述2：
"那么如果要看运气的话，物理资源多少才算闲置，总利用率多少需要开始关注CPU亲和度了，需要开始着手处理此类问题了"
A2：
首先要理解亲和度的概念，是CPU是否能从cache1、2、3里面读到数据。举个例子，有1000个进程跑在一个CPU上，但都是不怎么干活的进程，一会儿进程A上来占用，一会进程B上来占用，但总体CPU利用率并不高，但每个进程上来后都要有自己的进程上下文。可能此时cache1、2、3根本缓存不了这么多上下文。结果就是大量的上下文切换。
因此不会有一个绝对的指标，说物理资源多少才开始关注CPU亲和度。
针对 “物理机的整体CPU利用率究竟达到多少时，需要考虑扩大LPAR的EC”
是否扩大LPAR的EC，主要考虑的是你的业务需求是否能够得到满足（例如，响应时间是否满足要求，吞吐量是否跟得上），而不是主要考虑物理机的整体CPU利用率。
