如何寻找性能瓶颈：
拿到项目先评测一下项目，了解大致的性能指标，以及测试环境的软硬件参数，如服务器网速带宽，CPU性能，运行内存大小，硬盘内存大小，单个完成事务占用带宽峰值；
项目性能主要看一下几个参数：
QPS（TPS）：每秒钟request（事务）数量，这是一个相对值，计算方法为：并发数*每秒请求服务端总数/响应时间；
并发数：系统同时处理的request（事务）数量；这个看具体项目的需求，在满足响应时间的前提下，并发数越多越好；
响应时间： 一般取平均响应时间，普遍的标准是2/5/10秒原则，也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验；在5秒之内响应客户被认为“比较不错”的用户体验；在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
以下是几个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，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。
以我的测试环境来看，先计算一下测试端各软硬件性能参数瓶颈：运行内存4G，双核CPU（型号），局域网百兆带宽，使用LoadRunner单独一个虚拟用户使用nmon监控服务器得到“登陆”环节占用带宽峰值为400 KB/S，在百兆局域网内，完整带宽为100M bps，转换成Byte，为100M/8=12.5 MB/S.根据经验，一般网络带宽瓶颈参数为0.7，即占用网络带宽70%以上，即可视为出现网络瓶颈。因此，实际有效带宽为12.5MB/S×70% = 8.75MB/S。因此在百兆局域网内，可容纳的并发用户数为8.75×1024/400= 22.4个用户。推论：目前系统在百兆局域网环境下，用户数超过22.4个，即可造成网络瓶颈，网络瓶颈的表现为系统响应速度变慢，但实际上应用服务器却是空闲状态，所以要达到500QPS,就要在22.4个用户并发以下通过精简、合并JavaScript代码或采用本地和Server缓存解决重复消耗的时间，否则只能提升测试环境的软硬件性能，通过增加虚拟用户来测试能否达到500QPS指标；（未完。。。）
