在性能较低的硬件上进行网站应用程序压力测试

Question

我的组织正在进行一场有趣的内部辩论，涉及到一个问题，我想向整个社区开放。

争议的焦点是我们进行压力测试、容量测试、性能回归测试等的环境。

在辩论的一方是一些软件工程师，他们希望这个环境尽可能模拟生产环境，以便结果更有意义。虽然我们目前有一个用于此类测试的环境，但它的能力远不如生产系统，这些软件工程师认为已经达到了从中学习的极限。

另一方面是一些网络工程师，他们管理这些环境并控制资金。虽然他们承认容量测试在更好地模拟生产环境的环境中会更好，但他们认为，为了进行压力测试，一个更谦虚的环境会放大性能瓶颈，使它们更容易发现和修复。

最后引起我的兴趣的是：一位软件工程师提出，尽管更谦虚的压力环境将增加遇到一些瓶颈的可能性，但并不一定能帮助你找到下一个你可能在生产中遇到的瓶颈。他认为，扩展效应可能不是线性的。

这种观点有道理吗？如果有，为什么？导致这种非线性的原因是什么？

这里涉及到许多复杂的部分：一组Java应用服务器、一组数据库服务器，为每个 HTTP 请求生成大量动态内容。

---

编辑：感谢大家迄今为止的想法，但我真的希望有人能够超越双方立场，并实际回答“为什么”的问题。如果存在这样的非线性，是什么造成了它？最好的情况是，理由可以用CPU、内存、带宽、延迟、子系统之间的交互等方面来表达...... TerryE，你已经很接近了。如果没有其他人参与，您应该将您的评论重新发布为悬赏的答案。

- pohl

---

如果你愿意的话，可以阅读并考虑一下：系统性能崩溃。所有的系统都会有一些限流组件。关键是要了解系统的饱和约束，并平衡子系统，使得这些子系统具有大致相同的吞吐量。同时确保没有无谓的低效子系统会影响整体性能。 - TerryE

Answer 1

你的软件开发人员是正确的，我会进一步说明这一点。

当你测试应用程序组件（例如 Web 服务）以查看其在负载下的行为时，使用较弱的环境是可以理解的。你可以找到有关内存、io等方面的瓶颈，并且很可能会发现错误和疏忽，例如内存不足错误和日志文件变得巨大。

但是当你的应用程序组件按预期运行并且你需要测试整个应用系统时，你需要测试真实环境。

当你在一个环境中进行压力测试时，你衡量的是该环境在负载下的行为和其瓶颈。虽然这些测试可能提供有价值的信息，但这些信息不会涉及你的生产系统。你找到的瓶颈可能与你的真实系统无关，你可能会花费宝贵的开发时间来修复不存在的错误。为了了解你可能真正面临的瓶颈，你应该在你的真实生产系统上进行压力测试（最好是在盛大开业之前）。

- ali köksal

---

我同意alikox的观点：你的开发人员是正确的。归根结底，必须测试和验证生产系统的性能。 - David Pettersson

Answer 2

网络工程师的假设是，适度的系统基本上是生产系统的缩小模型。他们还假设，生产环境中影响软件性能的各种特征在更为适度的系统中也存在，只是在较低的水平上以相同的比例映射出来。例如，CPU 不是那么快，内存不够多，存储速度有点慢等等，所有这些差异都是在类似的比例下发生的，因此如果每个因素都被某个因子（比如1.77）神奇地乘以，那么所得到的改变后的适度系统将完全像生产系统一样。

然而，我很难相信适度系统在所有细节方面都是生产系统的精确缩小模型。

以下是一个具体的例子。假设对生产系统进行的测量表明 CPU 利用率（CPU 非空闲时间的百分比）过高。于是你将软件放在适度系统上进行测量，并发现在适度系统上，CPU 利用率更低。调查发现，适度系统的存储速度较慢，因此 CPU 在等待从存储器传输数据完成时会花费更多的时间处于空闲状态，因为应用程序在适度系统上受到 I/O 限制，而在生产系统上则不是这样。这种差异是由于适度机器与生产机器的 CPU 比率与 I/O 传输比率不同，因此适度机器并不是生产机器的精确缩小模型。

另一个例子是拥有更多内存可以在生产环境中减少页面错误。当软件加载到较为简陋的机器上时，由于物理内存较少，会出现更多的页面错误。各种应用程序分页进出时，它们开始相互影响，因为其他应用程序的页面被交换出去，然后再次交换回来。在具有更大内存的产品机器上，不会出现这种级联页面错误行为，因为有足够的内存同时运行更多的应用程序。

我真正想要表达的观点是，计算机及其各种部件和应用程序是一个复杂的动态系统。认为一个计算环境只是另一个的缩小版是过于简单化的假设。使用简陋的系统确实可以提供有价值的数据。然而，一旦对软件进行了粗略的调整，并且您开始进行更细微的详细调整，环境的差异可能会对测试结果产生重大影响。

一些引文。 计算机系统是动态系统 by Tod Mytkowicz、Amer Diwan 和 Elizabeth Bradley。

Bayesian fault detection and diagnosis in dynamic systems由Uri Lerner、Ronald Parr、Daphne Koller和Gautam Biswas撰写，涉及编程相关内容。

- Richard Chambers

---

感谢您的回应。它深入挖掘了我的好奇心所在。 - pohl

Answer 3

我在生产环境中遇到了类似的情况。我们使用简单的系统进行初始和基本级别的测试和发现。事实是，在测试环境中你永远无法找到真正的瓶颈和其他性能问题。因此，要找到真正的性能相关问题和瓶颈，必须在生产环境中进行，没有其他方法。

我们托管了超过250万个网站，虽然在您的情况下可能不是这样，但是让我告诉您，在我们的情况下，我们面临了可怕的线性瓶颈。这意味着，当我们的流量增加时，我们首先遇到了内存问题。我们通过添加更多的内存来解决了这个问题。直到那时，我们甚至没有注意到只有256个httpd线程是我们下一个瓶颈，因为有限的内存隐藏了它，一旦我们解决了内存问题，它很快又出现了问题，为什么我们的Web服务器再次变慢了？我们发现256个httpd线程根本无法服务那么多的流量。我们不仅增加了线程，还在我们的Web服务器前安装了HA并行负载均衡器以缓解问题。

幸运的是，它解决了我们的页面加载缓慢的问题。但是几个月后，随着流量不断增长，我们遇到了下一个存储系统的瓶颈。这次磁盘I / O是问题所在。长话短说，我们使用了基于并行NFS的物理存储系统。每个NFS机器现在通过运行超过2000个线程来提供文件服务。

我忘了提到数据库也是慢的罪魁祸首，我们通过在集群中安装主从模型来解决了这个问题。我们还必须对应用程序代码进行大量性能调整，并将应用程序物理分布到不同的服务器上的不同模块中。

我只是提到所有这些来证明一点，即所有与性能相关的问题几乎以线性方式出现，至少在我们的WebBased模型中是这样。即使您在简单的系统上进行了大量测试，您仍然有可能隐藏了一些瓶颈，在测试环境中找不到。

根据我的过去6年的经验，如果您认为可能会有很多流量或点击/秒，请尽可能地分发您的模型。通过进行许多调整，集中式模型可以暂时承载您的流量，但最终您的系统会崩溃。

我不是说您将在您的情况下面临一些瓶颈或问题，但我只是想警告您有时会发生这些情况，以便您更好地了解。

**对我的英语表示歉意。

- Humayun

Answer 4

我们每天为客户进行系统负载测试，并看到各种各样的问题。某些类别的问题可能会出现在规模较小的系统上，而其他问题则不会。有些问题只能在生产中发现……因为无论您多么接近两个系统，它们永远不可能完全相同。如果您足够努力，可以非常接近。

因此，测试的简单事实是：您的系统越接近生产系统，您的测试就越准确。

在我看来，这是迁移到云端的最佳原因之一：您可以启动一个与生产系统非常接近的系统（几乎完全相同），并在其中运行负载测试。

值得一提的是，我们偶尔会看到客户在测试环境中浪费大量时间去追踪在生产中永远不会发生的问题。环境差异越大，这种情况就越有可能发生。:(

- CMerrill

Answer 5

我认为您已经部分回答了自己的问题 - 您已经拥有一个生产级环境，并且已经发现它与生产环境不在同一水平/不如生产环境强大。归根结底，即使有无尽的资金，您也永远无法复制生产网站的确切功能 - 事件时间、容量、CPU利用率、内存利用率、数据库IO等等，当所有这些都在愤怒地工作时，行为可能是非确定性的。我的观点是您永远无法完全做到相同。而另一方面，生产环境本质上是一个昂贵的环境，需要很多设备才能使其执行并处理您的数据/交易生产量。这是业务的一项巨大开销/开销，在这个节俭的时代，我们不应该寻求避免对业务的额外成本吗。

也许应该采取不同的策略-学习您的生产软件的性能配置文件-它如何随着容量扩展，运行时间是否呈线性增长、指数增长还是对数增长？你能建模吗？首先，您可以验证测试环境是否以类似的方式运行-这对于拥有有效测试至关重要。然后，另一个重要部分是进行相对测试而不是绝对测试-您不会得到与生产相同的绝对运行时间，但在部署代码更改之前运行性能测试以给出基线，然后部署代码更改并重新运行性能测试-这将为您提供生产中的相对变化（例如，此代码发布是否会降低性能），根据您的性能模型，您将能够验证软件随着额外容量的扩展以相同的方式扩展。

因此，我的观点是，在较低的环境中，您可以学习有关软件和硬件性能的大量信息，并且在较小/不那么强大的基础设施上进行此操作可以为公司节省资金，并且如果正确使用，可以为您提供大部分所需的性能测试答案。

- k_guk

Answer 6

很好的问题。学习和优化最好在适度的硬件上进行。但测试最好在镜像上进行（或者至少是同一时代的东西）。

看起来你试图预测将出现的第一个瓶颈以及它何时会发生。我不确定这是否是正确的目标和正确的方法。我假设我们不谈论典型的CRUD，其中客户端说“它应该像其他每个Web应用程序一样快速工作”。如果您想正确地进行测试，则应在开始测试之前知道预期的负载。预期用户数量、预期事件数量、响应时间等都是产品规格的一部分。如果您没有这些数字，那么意味着您的分析师没有做好他们的工作。

如果您有这些数字，则不需要精确的测试结果。您只需要知道数量级。您还应检查软件/硬件的扩展能力。需要多少实例才能处理x个用户/请求/任何事情，需要多少实例才能处理y个用户/请求/任何事情。

- piotrek