QPS/TPS的预估

先说标准概念：

TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每一个呼叫平均TPS）

QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，做为域名系统服务器的机器的性能常常用每秒查询率来衡量

 

区别：

Qps基本相似于Tps，可是不一样的是，对于一个页面的一次访问，造成一个Tps；但一次页面请求，可能产生屡次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

例如：访问一个页面会请求服务器3次，一次访问，产生一个“T”，产生3个“Q”

 

并发用户数和qps两个概念没有直接关系，可是若是要说qps时，必定 须要指明是多少并发用户数下的qps，不然豪无心义，由于单用户数的40qps和20并发用户数下的40qps是两个不一样的概念。前者说明该应用能够在一 秒内串行执行40个请求，然后者说明在并发20个请求的状况下，一秒内该应用能处理40个请求。

 

保证天天多少pv的并发链接数的计算公式是：  并发链接数＝ pv / 统计时间(一天是86400) * 页面衍生链接次数 * http响应时间 * 因数 / 服务器数量

保证4千万pv的并发链接数：  (40000000pv / 86400秒 * 10个派生链接数 * 5秒内响应 * 5倍峰值) / 6台服务 = 19290链接数

 

采用8/2原则。即80%的请求访问在20%的时间内到达。此时根据系统pv测算出qps值 
峰值qps=（总Pv * 80%）/（60*60*24*20%）。 

例如500W访问，预估QPS: (500W * 0.8) / (60*60*24*0.2) = 400W / 17280 = 232

而后再将峰值qps/单台能承受的最高qps，就是须要的机器数量。 机器数= 总峰值pqs/压测单台机子极限qps

例如一台机器的最高QPS是50，要的机器数量为：232 / 50 = 5(台)

 

QPS = 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间
一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登陆签到系统进行签到。公司员工为1000人，平均每一个员上登陆签到系统的时长为5分钟。能够用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60  秒
并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7

 

---------------------------------------------

网站按访问QPS分类：

50QPS如下——小网站

没什么好说的，简单的小网站而已，你能够用最简单的方法快速搭建，短时间没有太多的技术瓶颈，只要服务器不要太烂就好。

50～100QPS——DB极限型

大部分的关系型数据库的每次请求大多都能控制在0.01秒左右，即使你的网站每页面只有一次DB请求，那么页面请求没法保证在1秒钟内完成100个请求，这个阶段要考虑作Cache或者多DB负载。不管那种方案，网站重构是不可避免的。

300～800QPS——带宽极限型

目前服务器大多用了IDC提供的“百兆带宽”，这意味着网站出口的实际带宽是8M Byte左右。假定每一个页面只有10K Byte，在这个并发条件下，百兆带宽已经吃完。首要考虑是CDN加速／异地缓存，多机负载等技术。

500～1000QPS——内网带宽极限＋Memcache极限型

因为Key/value的特性，每一个页面对memcache的请求远大于直接对DB的请求，Memcache的悲观并发数在2w左右，看似很高，但事实上大多数状况下，首先是有可能在次以前内网的带宽就已经吃光，接着是在8K QPS左右的状况下，Memcache已经表现出了不稳定，若是代码上没有足够的优化，可能直接将压力转嫁到了DB层上，这就最终致使整个系统在达到某个阀值之上，性能迅速下滑。

1000～2000QPS——FORK/SELECT，锁模式极限型

好吧，一句话：线程模型决定吞吐量。无论你系统中最多见的锁是什么锁，这个级别下，文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点，全部的数据都必须分布存储，数据须要分布处理。总之，关键词：分布。

2000QPS以上——C10K极限

尽管如今不少应用已经实现了C25K，但短板理论告诉咱们，决定网站总体并发的永远是最低效的那个环节。