本节书摘来自异步社区《大型网站服务器容量规划》一书中的第3章，第3.2节,作者： 郑钢 更多章节内容可以访问云栖社区“异步社区”公众号查看。
3.2 通过压力测试规划容量
为了获得系统的容量，专业一点的公司都会让运维人员搭建一套线下的测试环境，让QA在线下测试，通过压力测试并结合监控来找出系统的极限值。最常见的压力测试工具有ab（Apache Bench）和Jmeter，它们是Apache项目提供的，可以在Apache官网中找到，还有LoadRunner也很不错。
虽然压力测试是以实际请求来度量容量，看似是最真实的，但这种做法其实并不准确，因为系统的实际压力负载和业务对应的具体指令紧密相关，而压力测试通常仅做一次，其结果仅与当时的业务代码相匹配，但凡有新代码上线后，由于涉及代码不同，其对应的指令通常也会不同，因此之前所做的压力测试便被推翻了。
也许有读者说，可以让QA人员每次都在新代码上线前都做回归测试。其实这一点并不靠谱，这说明不了解QA的工作。压力测试中要检查（也称回归测试）的测试用例非常多，这需要QA人员极大的耐心，而且线下测试机往往用淘汰下的机器，其性能与线上服务器的性能差别很大，这注定了测试结果的不准确性。
既然压力测试也不完全靠谱，那应该怎么做呢？有的公司是这样做的，用真实流量导向待测试的服务器，也就是用线上实际压力去做压力测试，观察机器负载或日志，直到出错为止。
如果集群中原本有10台服务器，先去掉其中的4台服务器，只让剩下的6台服务器提供服务，测试人员通过观察机器压力负载或日志中输出的信息等手段来判定服务的稳定性。如果服务正常的话，继续从集群中下掉一些服务器，直到服务器压力越来越大，线上业务报错为止。毋容置疑，这肯定是最真实的测试结果。当然这需要魄力，哈哈……反正我不敢，无论业务是多么不重要，也不能牺牲用户体验来测试极限容量。
