QPS、TPS

问题一:你项目的qps有多少?

QPS(Query Percent Second ):一秒内可以处理的请求数量称之为服务器的QPS。

TPS:Transactions Per Second(每秒处理的事务处理数量),即服务器每秒处理的事务数。

公式计算:一般是根据系统的最高的TPs和日PV。然后根据时长计算出来。

一、计算公式是:1/t*n= qps

t就是每个请求的响应平均时长,n为请求数

假设:用户查询的平均响应时间是:100毫秒

如果一次性可以处理100请求,每秒请求耗时是100毫秒,则QPS=1000
如果一次性可以处理50请求,每秒请求耗时是200毫秒,则QPS=250
根据公式:1(秒)/100(毫秒) == 1s/0.1秒 * 100 = 1000
根据公式:1(秒)/200(毫秒) == 1s/0.2秒 * 50 = 250

二、每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间。

公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。

机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。

例:每天300w PV 的在单台机器上,这台机器需要多少QPS?

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。

一般需要达到139QPS,因为是峰值。

问:如果一台机器的QPS是58,需要几台机器来支持?

答:139 / 58 = 3

那么如何提升你的QPS请求数。

1:提升的你的单机并发数,比如增大线程
2:修改你接口,把你接口每秒的响应时间缩短

而修改接口提升接口的响应时间,大部分都是用缓存

1000qps算大吗?

这个问题一定不能直接给答案,一定是要看业务和接口。

分两个层面回答,比如如果我们就是访问一些页面和静态资源。那么这个值就很小。但是,在开发中我们处理的业务和接口,肯定不是简单的访问页面这么简单,比如:注册,下单,用户查询等。因为业务接口的访问整个过程包括:tcp链接时间 + 数据库的TCP时间+网络的时间 +javajvm运行程序的时间 来决定的。

根据我自己平时公司测试的数据和指标在  CPU为4核、内存8G、硬盘7200转、带宽10M的情况下,对下单接口进行测试我得出的结论是:下单的平均时间是:120ms 左右 ,java程序tomcat的线程并发数:400 没有出现任何问题的或者极少出现问题的情况下:
       1/0.12 * 400 =  3000多。

注意这只是:QPS = 3000底盘,如果默认的tomcat线程数是:200 不改,QPS =  1600,所以1000不算很大。当然QPS=1000不能单纯的根据感官去衡量,而是要根据不同的业务以及电脑的配置和运行时间才计算,就算通过专业的测试来计算也不一定就能保证任何问题,都要根据电脑配置,硬件,业务一起来决定。得到一个相对参考的值。

QPS=3000 这么大,是不是意味着每秒可以下单3000呢?当然不是。QPS是每秒的请求数,就好比我们用AB或者jemter的压测,或者用户正常的去访问一样。这3000代表就是你的客流,你能承载。这3000人有多少人。你每秒中能处理多少人正常的入座到离开的完整过程称之为:TPS

QPS=3000就是流量来了。TPS:事务每秒数

这个东西就不是java所能决定的啦。主要得看两个要素:第一个要素:java多线程 + MYSQL的多线程理论上:java开400并发线程,MYSQL也应该同时执行400个线程任务。来维持事务,也就是每秒可以处理事务数量是:tps = 400/s,也就是可以1秒下单400。但是现实是很难的。1:java高并发下单的情况下,单机400下单,除非你这个服务器专门用于下单,而且MYSQL肯定要更改最大连接数,默认是:151,调大以后,理论上也可以每秒处理400订单,但是还是不可能,因为MYSQL的服务和jvm一样,除了处理订单还在处理别的业务CURD,也就是说:400的javatomcat线程全部用上,也不一定能够每秒下单400,因为这400里肯定还在处理别的业务和能力。

怎么办
1:把下单服务进行独立化部署。
2:单价维持在每秒下单400~600就是一个很不错的值了。

一般稳定在400就OK了,然后集群把订单服务做集群

比如:100个订单服务器,每秒就下单:40000了

一般单机在高并发的场景下,全部集中在一个服务器是很难每秒达到极限值400.一般估计维持在 几十到200左右,当然在集群的之前我们可以还用读写分离,这也是为啥用读写分离的原因。读一个服务器,写一个服务器,这样可以提升下单能力。但是也不可能说达到400,小型网站就用:读写分离就很好解决,中大型项目:最好是用集群,协同下单。

TPS:Transactions Per Second(每秒处理的事务处理数量),即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出,加上一次用户数据库访问。(业务TPS = CAPS × 每个呼叫平均TPS)。一般的,评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值,TPS越高代表系统的性能越好,但同时服务器的压力也更大。

一般计算:你们就理论值,并发线程 200,但是200不可能全部处理某一个业务。根据二八 原则都不可能达到

qps 请每秒请求数   ---每秒接受的请求数
tps 
是吞吐量 ----每秒接受处理的请求数
每秒并发 10000 ----并发数-----饭店来了 10000个客人,QPS代表每秒接客的人数(就是饭店内的座位和外部等待的位置数量),TPS就是:真实落座的人数和服务人数,tps讲究的是:request和response完整的过程。来了上200座位坐满吃饭,但是饭店有些人是吃饭,有些人是喝粥,也写人就是来吃火锅
 

 

问题2:如果让你来设计一个系统,你会怎么做?

1、先确定项目的需求和内容,比如:项目的文档,项目对接相关人员,以及后续的相关的人。
2、然后在确定项目的开发周期,和开发相关的文档。
3、然后会和老板或者项目负责人确定开发的人员和团队,进行人员的协调和分配,还是招聘人员
4、然后同时可能开始和产品经理细化产品的功能和模型。与此同时我可以开始根据团队的人员技术情况以及项目的周期选择合理的架构类型
5:开始协调一部分人开始攻克项目的存在的一些技术难点和问题。
6:然后找到对应的UI进行设计页面,开始抓项目的进度和周期。
7:然后调度测试和开发进行项目的评估和测试,和修复BUG工作
8:然后确定产品的发布事件和时间周期。总结项目存在的问题和改进点。

  • 10
    点赞
  • 52
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值