为什么容器是测试软件性能的最佳方式

当我们谈论应用程序开发时，软件性能和可扩展性是经常出现的话题。一个重要的原因是应用程序的性能和可扩展性直接影响其在市场上的成功。一个应用程序，无论其用户界面多么出色，如果其响应时间缓慢，就无法占领市场份额。

这就是为什么我们花费大量时间来改进应用程序的性能和可扩展性，随着其用户群的增长。

常规测试实践失败的地方

幸运的是，我们有很多工具来测试软件在高压力条件下的行为。还有一些工具可以帮助识别性能和可扩展性问题的原因，以及其他基准测试工具可以对系统进行压力测试，以提供系统在高负载下相对稳定性的度量；然而，当我们尝试使用这些工具来了解企业产品的性能时，我们在性能和规模工程方面遇到了问题。通常，这些产品不是单个应用程序；相反，它们可能由几个不同的应用程序相互交互组成，以提供一致和统一的用户体验。

如果我们仅测试产品的各个组件，我们可能无法获得有关产品性能和可扩展性问题的任何有意义的数据。只有当我们在真实场景中测试应用程序时，即通过使整个企业应用程序承受真实的工作负载，才能收集到真实的数据。

问题变成：我们如何在测试场景中实现这种真实的工作负载？

容器来救援

答案是 容器。为了解释容器如何帮助我们理解产品的性能和可扩展性，让我们以 Puppet（一种软件配置管理工具）为例。

Puppet 使用客户端-服务器架构，其中有一个或多个 Puppet master（服务器），以及要使用 Puppet 配置的系统运行 Puppet agent（客户端）。

为了了解应用程序的性能和可扩展性，我们需要用在各种系统上运行的代理程序的高负载来压力测试 Puppet master。

为此，我们可以在一个系统上安装 puppet-master，然后运行多个容器，每个容器都运行我们的操作系统，然后在操作系统上安装并运行 puppet-agent。

接下来，我们需要配置 Puppet agent 与 Puppet master 交互以管理系统配置。这会在服务器处理请求时对其施加压力，并在客户端更新软件配置时对其施加压力。

那么，容器在这里有什么帮助？难道我们不能只通过脚本来模拟 Puppet master 上的负载吗？

答案是否定的。它可能模拟了负载，但我们会得到对其性能的高度不真实的看法。

原因很简单。在现实生活中，用户系统除了 puppet-agent 或 puppet-master 之外，还会运行许多其他进程，其中每个进程都会消耗一定数量的系统资源，因此直接影响 puppet 的性能，限制了 Puppet 可以使用的资源。

这是一个简单的示例，但是当处理结合了十几个以上组件的产品时，企业应用程序的性能和规模工程可能会变得非常具有挑战性。这就是容器的闪光点。

为什么是容器而不是其他东西？

一个真正的问题是：为什么使用容器而不是虚拟机 (VM) 或裸机服务器？

运行容器背后的逻辑与我们可以启动的系统容器镜像的数量以及它们相对于替代方案的成本有关。

尽管虚拟机提供了一种强大的机制，但它们也会给系统资源带来大量开销，从而限制了可以在单个裸机服务器上复制的系统数量。相比之下，在同一系统上轻松启动甚至 1,000 个容器是相当容易的，具体取决于您尝试实现的模拟类型，同时保持较低的资源开销。

使用裸机服务器，性能和规模可以根据需要达到真实水平，但主要问题是成本开销。您会购买 1,000 台服务器来进行性能和规模实验吗？

这就是为什么总体而言，容器提供了一种经济且可扩展的方式来测试产品在真实场景下的性能，同时控制资源、开销和成本。

在 Saurabh Badhwar 在洛杉矶 开源峰会 上的演讲 使用容器测试软件性能和可扩展性 中了解更多信息。