吞吐量、响应时间和CPU利用率之间的关系
发布时间：2025-04-18 点击：8
在实际的生产运行、测试过程中，一般都会关注吞吐量、响应时间、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利用率。
令人会心一笑的先进营销法则
SEO文章内容优化需注意什么
德州网络推广「seo监测」站长查询东西怎么成为站长的得力助手？
网站设计需求的方案有什么内容
做网站一定要注意的问题
如何做好微信群营销?
seo赚钱方法大揭秘 赚钱其实很简单
建站设计要根据用户进行规划
吞吐量和响应时间的关系
这里先举一个例子，通过计算，发现测试结果不可信的例子。
该场景是服务器并发处理业务报文，并且达到了大处理能力(即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利用率。
令人会心一笑的先进营销法则
SEO文章内容优化需注意什么
德州网络推广「seo监测」站长查询东西怎么成为站长的得力助手？
网站设计需求的方案有什么内容
做网站一定要注意的问题
如何做好微信群营销?
seo赚钱方法大揭秘 赚钱其实很简单
建站设计要根据用户进行规划