# 如何进行压力测试

压力测试很有趣，一开始好像压测的目的是找出系统在负载下能不能工作。现实中，系统在负载下确实能工作，但在负载足够重的某些情况下不能工作。我把这叫做*碰壁*或*撞响*\[1]。可能会有例外，但大多数情况下会有这么一堵“墙”。压测的目的是为了指出墙在哪里，然后弄清楚怎么把墙移得更远些。

压测计划需要在工程的早期就规划好，因为它经常有助于弄清楚到底什么是被期望的。两秒的网页请求是一个悲伤的失败还是一个了不起的成功？500个并发用户是否足够？这，当然，视情况而定，但一个人在设计系统时就应该知道满足需求的答案。压测需要足够好地为现实建模，使之足够有用。非常容易地模拟500个不稳定并且不可预测的人并行使用系统不是真的可能的，但我们可以至少创造500个模拟（用户），然后尝试模拟他们可能做的部分事情。

在压测中，从轻负载开始，然后为系统在一些维度上增加复杂 - 比如输入频率和输入规模 - 直到你抵达那堵墙。如果墙太近了以至于不能满足你的需要，弄明白哪个资源是瓶颈（这通常是那个主要的资源）。它是内存？处理器？I/O？网络带宽？还是数据连接？然后弄明白你可以怎么移动那堵墙。记录下移动墙的那个要素，也就是增加了系统可以处理的负载的那个要素，它可能不能真正在低负载系统下产生危害。但通常重负载下的表现比轻负载下更重要。

你必须能够观察几个不同维度，以此来为之构建一个思维模型；单一的技术是不够的。例如，日志经常是给出系统中两个事件间的挂钟时间的好主意。但除非仔细构建，日志不会给出内存使用的可见性甚至是数据结构的大小。相似的，在现代系统里，大量电脑和许多软件系统是合作的。特别是在你碰到那堵墙时（也就是，表现与输入不成线性比例时），这些软件系统可能成为瓶颈。对这些系统的透视力，甚至仅仅对所有参与工作的机器的处理器做测量，都可能是非常有帮助的。

意识到墙在哪里的关键不仅是移动这堵墙，而且也是提供对其的预测能力。这样公司可以得到更高效的管理。

***

\[1] "撞响"

Next [如何在简洁与抽象间平衡](https://braydie.gitbook.io/how-to-be-a-programmer/zh-traditional/2-intermediate/personal-skills/05-how-to-balance-brevity-and-abstraction)