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，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节
QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
ab常用参数的介绍：
-n ：总共的请求执行数，缺省是1；
-c： 并发数，缺省是1；
-t：测试所进行的总时间，秒为单位，缺省50000s
-p：POST时的数据文件
-w: 以HTML表的格式输出结果
执行测试用例：ab -n 1000 -c 100 -w http://localhost/index.php >>d:miss.html
上面的测试用例表示100并发的情况下，共测试访问index.php脚本1000次，并将测试结果保存到d:miss.html文件中。
Document Path:测试页面
Document Length: 页面大小
Concurrency Level: 测试的并发数
Time taken for tests:整个测试持续的时间
Complete requests:完成的请求数量
Failed requests: 失败的请求数量
Write errors: 0
Total transferred: 整个过程中的网络传输量
HTML transferred: 整个过程中的HTML内容传输量
Requests per second: 最重要的指标之一，相当于LR中的每秒事务数，后面括号中的mean表示这是一个平均值
Time per request: 最重要的指标之二，相当于LR中的平均事务响应时间，后面括号中的mean表示这是一个平均值
Time per request: 每个连接请求实际运行时间的平均值
Transfer rate: 平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题
Percentage of the requests served within a certain time (ms) 50% 25 ## 50%的请求在25ms内返回 66% 26 ## 60%的请求在26ms内返回 75% 26 80% 26 90% 27 95% 31 98% 38 99% 43 100% 48 (longest request)