先说标准概念：
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，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。