pv qps 并发 的摘要【重要】
https://zhidao.baidu.com/question/1495951065865595059.html
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间
公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) qps:pv=1:6*3600
机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器
问:每天300w PV 的在单台机器上,这台机器需要多少QPS?
答:( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问:如果一台机器的QPS是58,需要几台机器来支持?
答:139 / 58 = 3
http://f.dataguru.cn/thread-480246-1-1.html
淘宝的TPS和PV之间的关系通常为 较高TPS:PV大约为 1 : 11*3600 (相当于按较高TPS访问11个小时,这个是商品详情的场景,不同的应用场景会有一些不同)
一个典型的上班签到系统,早上8点上班,7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人,平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60 秒
并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7

开始,系统只有一个用户,CPU工作肯定是不饱合的。一方面该服务器可能有多个cpu,但是只处理单个进程,另一方面,在处理一个进程中,有些阶段可能是IO阶段,这个时候会造成CPU等待,但是有没有其他请 求进程可以被处理)。随着并发用户数的增加,CPU利用率上升,QPS相应也增加(公式为QPS=并发用户数/平均响应时间。)随着并发用户数的增加,平均响应时间也在增加,而且平均响应时间的增加是一个指数增加曲线。而当并发数增加到很大时,每秒钟都会有很多请求需要处理,会造成进程(线程)频繁切换,反正真正用于处理请求的时间变少,每秒能够处 理的请求数反而变少,同时用户的请求等待时间也会变大,甚至超过用户的心理底线。
http://www.chinaz.com/web/2016/0817/567752.shtml
PV计算带宽
计算带宽大小需要关注两个指标:峰值流量和页面的平均大小。
举个例子:
假设网站的平均日PV:10w 的访问量,页面平均大小0.4 M 。
网站带宽 = 10w / (24 *60 * 60)* 0.4M * 8 =3.7 Mbps
具体的计算公式是:网站带宽= PV / 统计时间(换算到S)*平均页面大小(单位KB)* 8
https://www.jianshu.com/p/6850175e3c0e
三、根据PV计算公式:
比如一个网站,每天的PV大概1000w,根据2/8原则,我们可以认为这1000w pv的80%是在一天的9个小时内完成的(人的精力有限),那么TPS为:
1000w*80%/(9*3600)=246.92个/s,取经验因子3,则并发量应为:
246.92*3=740
12.28补充一个案例
公司测试3个,男性240人,假定在9-10点上厕所
那么
qpm = 240 / 60 = 4人次/分钟
并发数3
平均响应时间 = 3/4 = 0.75分钟
这就是说,每人的上厕所时间需要达到0.75分钟
实际情况是平均每人等待+办事时间=15分钟
qpm=并发数/平均响应时间=3/15 = 0.2 qpm 远达不到 4 的数值
实际在这一小时内服务的人次=0.2 * 60分钟=12人次
那么如果要满足240人在一小时内搞定,需要多少坑位呢?
qpm=4人次/分钟
平均响应时间15分钟
并发数=qpm*平均响应时间=4*15=60坑位
2025年1月
0只是代表这个系统当时的并发数,并不代表系统可承载的极限并发数
假如10核CPU那么极限并发数并不一定=10
如果10之前,qps达到峰值,那么极限并发数<10
如果到10了qps仍未达到峰值,那么极限并发数>10
为什么10核CPU极限并发数是可以>10的,但上坑的极限并发数只能是3?
qps的研究对象往往是复合的,比如一次请求,程序是一些列IO、CPU活动的组合,但上坑是个相对单一的研究对象
这就是为啥8核cpu的极限并发数可以大于8
当然假如一个研究对象是纯cpu密集型,那么理论上极限并发数就是8
另一方面,假如我们试图进一步拆解上坑这一研究对象,那么它的极限并发数也是可以大于坑位数的
如果以坑位作为例子,如果把如厕进一步细分,比如脱裤子、进行、清洗、穿,那么极限并发数是可以>坑位数的,因为脱、清洗、穿这三个子任务严格来说并不需要用到CPU(马桶),可以出去弄,后一个就能进来;那么极限并发数就>坑位数了,所以坑位数并不等于极限并发数
相对来说,地铁进站这个例子更纯粹不可再分
https://www.cnblogs.com/miaomiaokaixin/p/17861779.html
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 | 一、问题 性能压测,如何评估一个系统的TPS和并发数? 二、回答 =》1.对于新系统 由业务部门或开发人员预估交易量和TPS指标,可以参考公式:并发用户=在线用户数* 10%。 当一个系统还没有上线时,我们可以预判的是这个系统准备要给多少人使用,如日常在线用户数量要支撑1000,那么并发用户参考值为:1000* 10%=100。 如果规定该业务的平均响应时间不高于500毫秒,那么通过TPS=并发用户数/业务平均时间,就可以得到TPS=100/0.5s=200笔/秒,为了系统健壮性考虑,我们还可以在预估计算得到的TPS基础上扩个1.5倍得到200笔/秒* 1.5=300笔/秒。 即可得到该系统的TPS为300笔/秒,并发数为150。 =》2.对于已上线系统 TPS有两个公式: 公式一:TPS=总请求/总时间,实际会考虑二八原则 公式二:TPS=并发数/业务平均时间 TPS一般有以下几种衡量系统性能指标的方式: 1.一般业务系统,选取一天业务量,根据二八原则估算TPS指标,二八原则即:80%的业务在20%的时间里完成,TPS=(业务量 * 80%)/(时间(单位s) * 20%) 2.秒杀类系统模型,选取高峰时间段业务量,估算TPS指标。 3.波动类、交易集中类系统模型,选取特殊交易时间段业务量,预估TPS指标。 另外需要注意:TPS指标需要考虑业务增长量相关因素 如某银行系统某业务订单数据如下: 日常8小时,100万笔交易量,高峰期间交易量8万笔,高峰持续时间9分钟,预估系统3年内每年业务增长率为20% 那么: 1. 该业务系统日常期间TPS为:TPS=(日常交易量 * 80%)/(时间 * 20%)=(100万 * 80%)/(8小时* 60 * 60 * 20%)≈139笔/秒 2. 该业务系统高峰期间TPS为:TPS=高峰期间交易量/高峰持续时间(单位s)=8万/9分钟* 60≈148笔/秒 3. 该业务系统包含每年业务增长率TPS为: 首先三年后业务量=日常交易量* (1+20%)* (1+20%)* (1+20%)=100万* 1.2* 1.2* 1.2=172.8万 其次被测业务交易占总业务交易比例为:40%,那么被测试业务交易量为:总业务交易量* 40%=172.8万* 40%=69.12万 最后被测业务包含每年业务增长率TPS为:(被测试业务交易量* 80%)/(时间(单位s) * 20%)=(69.12万* 80%)/8小时* 60 * 60 * 20%)=96笔/秒 一般情况下,为了系统健壮性考虑,我们会在预估计算得到的未来的TPS基础上扩个1.5倍,即:该业务系统包含每年业务增长率TPS为=96*1.5倍=144笔/秒。 4. 该系统性能测试最低支持的并发数为: 如果规定该业务的平均响应时间不高于500毫秒,那么通过TPS=并发用户数/业务平均时间,就可以得到并发用户数=0.5秒*144笔/秒=72个,即系统最低要求支持的并发数为:72个 说明:这里平均响应时间不同的公司不同业务可接受的响应时间是不同的,一般对于在线实时交易: 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右 金融企业:1秒以下为佳,部分复杂业务3秒以下 保险企业:3秒以下为佳 制造业:5秒以下就行。 即可得到该系统的TPS为144笔/秒,并发数为72个。 =》3.横向TPS扩展 假设单节点我们通过上面的方法,计算出来的TPS为150笔/秒,平均响应时间不高于500毫秒,并发用户数75个 现在我们想要系统支撑高并发数,通过扩展服务器数量来提升业务处理的能力,那么,我们也可以计算横向TPS扩展增长率: 1. 单节点TPS:150笔/秒 2. 2节点TPS:265笔/秒,则增长率为:(2节点TPS-单节点TPS)/(2节点-1)/单节点TPS=(265-150)/(2-1)/150≈76.67% 3. 3节点TPS:375笔/秒,则增长率为:(3节点TPS-单节点TPS)/(3节点-1)/单节点TPS=(375-150)/(3-1)/150≈75% 4. 4节点TPS:488笔/秒,则增长率为:(4节点TPS-单节点TPS)/(4节点-1)/单节点TPS=(488-150)/(4-1)/150≈75.11% 5. 5节点TPS:600笔/秒,则增长率为:(5节点TPS-单节点TPS)/(5节点-1)/单节点TPS=(600-150)/(5-1)/150≈75% 6. 6节点TPS:715笔/秒,则增长率为:(6节点TPS-单节点TPS)/(6节点-1)/单节点TPS=(715-150)/(6-1)/150≈75.33% 7. 7节点TPS:825笔/秒,则增长率为:(7节点TPS-单节点TPS)/(7节点-1)/单节点TPS=(825-150)/(7-1)/150≈75% 8. 8节点TPS:940笔/秒,则增长率为:(8节点TPS-单节点TPS)/(8节点-1)/单节点TPS=(940-150)/(8-1)/150≈75.24% 9. 9节点TPS:1050笔/秒,则增长率为:(9节点TPS-单节点TPS)/(9节点-1)/单节点TPS=(1050-150)/(9-1)/150≈75% 10. 10节点TPS:1165笔/秒,则增长率为:(10节点TPS-单节点TPS)/(10节点-1)/单节点TPS=(1165-150)/(10-1)/150≈75.19% 一般情况下,我们要求扩展服务器的数量进行高并发的处理,TPS增长率应在75%以上。 |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异
· 三行代码完成国际化适配,妙~啊~