但是，如果系统上线后，重大故障频发，频遭用户投诉，怎么办？前天是系统服务器 CPU 100% ，导致无法响应客户请求；昨天是 数据库 锁表，大量 数据库 连接阻塞，无法获取需要的数据；今天是某个接口在高并发下出现异常……每天，我们在不停的灭火和陪笑，无止境的抱怨消耗着我们本不多的耐心。
靠人人跑，靠树树倒，只有自己拯救自己了，但要如何才能拯救我们自己于水火之中呢？最重要的技术手段，恐怕就要靠 系统压力测试 了。
系统压力测试 不应该仅仅是孤立的测试各个软硬件的性能指标，而最重要的是要与软件应用系统结合，尽可能的模拟真实的业务场景和数据，从而充分评估系统上线后可能发生的情况。也就是说，当业务量达到高峰时，各个服务器 CPU 指标大概是多少，内存指标大概是多少，当大量数据被查询时，数据库的响应时间是多久， IO 、网络是否有问题？所有这些都应当事先被测量。
那么，如何去测量这些内同？主要就是以下方法：
1 、确定存量数据的规模（一般应至少制造出 3 － 5 年的存量数据，足够的数据才能测出实际的效率和性能）；
2 、确定需要进行 系统压力测试 的业务（一般是用户使用最频繁，或者业务操作最复杂的业务，比如各类的分析报表等）；
3 、确定操作用户的的数量、各类操作用户的比例；
4 、峰值业务量的要求（一般是 1 个小时内最多要处理的笔数）；
5 、对实时业务响应时间的要求（如在峰值情况下，一项操作的处理时间（如小于 20S ））；
当我们详细测试了每一个主要性能，消除了其中隐含的性能故障；当我们设计了完整 系统压力测试 方案，按照系统实际压力进行测试，再用 2 倍的压力、 3 倍的压力测试……我们消除了一个又一个系统瓶颈，仔细检查每一个细节，找不到错误的理由。现在，在系统性能方面，我们已经无法做的更好，因为我们已经做了所有应该做的事，和所有能做的事。
最后，时间会验证我们的 系统压力测试 结果。
欢迎您到我在 百洋软件实验室的正式博客 里留言讨论
本文 做好系统的压力测试 的方法转载自百洋软件实验室
