负载测试很困难，工具也不是很好。 但为什么？

如果您正在构建需要扩展的应用程序-我们都告诉我们自己是这样-那么在某个时候，您必须确定它是否可以扩展。这就是进行负载测试的地方：如果要查看应用程序是否可以处理规​​模，只需生成规模并查看它是否可以处理！听起来很简单。

然后，您尝试实际产生负载。如果您的应用程序非常简单，那么这很简单，因为您可以使用Apache JMeter之类的东西来生成重复请求。如果您可以这样做，我会羡慕您：我处理过的每个系统都更加复杂，并且需要更复杂的测试计划。

您的应用程序变得稍微复杂一些，因此您需要使用诸如Gatling之类的工具。这些功能使您可以模拟虚拟用户在各种情况下的浏览情况，这比围困一个或几个URL有用得多。如果您编写的应用程序在长期存在的会话中同时使用WebSocket和HTTP调用，并且还需要在计时器上重复某些操作，那么即使这还不够。除非我严重错过了文档中的内容，否则无法看到一种方法，例如设置运行30秒的心跳信号，在响应WebSocket消息时执行某些操作以及执行一些其他HTTP操作（所有操作都使用相同的HTTP）会议。我尚未在任何负载测试工具中找到一种方法来做到这一点（这就是为什么我在工作中编写自己的工具的原因，如果我能抽出时间清理并分离出专有位，我希望将其开源） 。

但是让我们假设您确实有一个像盖特林或蝗虫这样的开箱即用的工具，它可以满足您的需求。大！现在让我们编写该测试。以我的经验，这是最难的一点，因为您必须首先弄清楚实际负载是什么样的—欢迎您在浏览日志时做一两天的疏through日志并记笔记，同时单击浏览器中的网络工具在您的Web应用程序中。然后，在知道实际负载是什么样之后，您就可以将其归结为应用程序的一个子集，以假装自己是用户，点击API，然后执行用户会做的事情。

而且我们还没有完成！很好，我们已经编写了负载测试并且很现实。但这是一个移动的目标，因为更新会不断更新。因此，现在您也遇到了维护问题：随着应用程序的更改，如何使负载测试保持最新状态？没有很好的工具可以做到这一点，几乎没有什么可以帮助您的。您必须将其作为过程的一部分，并希望您不要错过任何事情。这不是一个令人满意的答案，这就是为什么这也是负载测试应用程序中最困难的部分之一的原因。

我们将跳过整个＆＃34;运行它部分，因为说实话，如果您已经通过负载测试走了那么远，那么运行它就不是最困难的部分。

大多数负载测试工具都支持简单的工作负载，即使是复杂的工作负载也不能让您完成模拟Web应用程序的实际使用所需的所有工作。

即使实际工具支持您所需的内容，编写具有真实使用情况的模拟的测试也是最困难的部分。

维护测试是第二困难的部分，此处的工具丝毫没有帮助您。

让我们详细研究这些内容，看看我们可以减少多少复杂性。

我是＆yes＆＃34;在这里，尽管它可能取决于您的应用程序。出于这些目的，我们正在谈论服务的用户；如果您拥有整体，则这是您的整体用户，但如果您有微服务，则＆＃34;用户＆＃34;可能是您的另一项服务！对于我从事的应用程序，在针对特定端点的目标测试中，我取得了较小的成功。但是这些最终都需要如此复杂的设置，以至于您不比负载测试本身更好！尽管它可能会产生一些结果和改进，但并不能解决所有问题（您可能具有交互的端点），并且无法获得实际的工作负载。

＆＃34;何时不需要模拟用户？＆＃34;可能是一个更好的问题。在我看来，这是当您知道端点在性能上都是独立的，没有任何有状态的请求，并且请求的顺序不会影响性能时。这些都是要承担的大事，如果不测试其独立性就很难对它们充满信心，这时，我们将重新编写整个测试。

您在此处可能要做的最好的事情是在API和系统设计时，而不是在测试时。如果您设计一个更简单的API，您将需要更少的表面积进行测试。如果您设计的系统中肯定有独立的部分（例如，每个服务的数据库不同），那么独立进行测试要比独立测试更容易。这样做还可以使您使用更简单的工具，从而获得两次胜利！

创建负载测试非常困难，因为您必须做一些事情：必须了解API使用的流向，以及必须编写对该使用的模拟。理解该流程意味着要理解除被测系统之外的其他系统，并且由于您的系统可能不是其文档的重点，因此不会有一个何时何地被调用的超清晰图；这通常看起来像筛选日志，直到您弄清楚代表性的用法是什么。然后编写该模拟当然不是一件容易的事，因为您需要管理代表API用户的大量参与者的状态！

有一些关于如何使其中一些任务更容易的研究。例如，您可以找出进行初始测试所需的条件，并通过对日志的自动分析来检测回归（缺少新的工作负载）。但是据我所知，GitHub上没有软件，更不用说我可以购买的产品了，它将为我做到这一点。因此，它似乎在行业中没有任何吸引力。自行实施将是一个很大的项目，这可能就是为什么它表现不佳（或在大公司完成，却没有被提及）的原因。

负载测试有很多复杂性，并且没有太多工具可以帮助您。因此，答案可能是：减少此类测试的编写，不要期望它们会为您提供有关系统性能的所有答案。

您可以通过以下几种方法来大致了解系统的性能：

好的旧分析。坐下来用笔记本，笔，对系统的整体了解以及一个下午的时间，您可以通过一些餐巾纸算出系统的一般参数和扩展范围。当您发现瓶颈时，或者您有一些未知数（我们的数据库每秒可以支持多少个事务？我们可以生成多少个事务？），您就可以进行专门的测试了！

功能推出。如果您可以在整个用户中缓慢推出功能，那么您根本不必进行任何负载测试！您可以通过实验评估效果，看看效果是否足够好。好？前滚。坏？回滚。

流量重播。这对新功能完全没有帮助（有关此功能，请参见十个单词前的功能介绍），但这确实有助于在不进行过多开发的情况下了解现有功能的系统突破点。您可以将以前看到的流量重新播放（甚至通过组合多个不同的时间段来进行多次播放），然后查看系统的性能！ （旁注：我很乐意使用工具来帮助解决此问题，并在这样做时增加流量，因此，如果有人提出建议，请来我这里。）

如果您错过了一些银弹，或者在该领域有出色的研究论文，则建议阅读，或者想要与我分享分享有关缩放的可怕故事，请通过电子邮件将它们发送给我@ ntietz.com。