15

我的组织现在正在进行一场有趣的内部辩论，这引发了一个我想向整个社区公开的问题。

手头的问题是我们在其中进行压力测试、容量测试、性能回归测试等的环境。

争论的一方是一些软件工程师，他们希望这个环境尽可能地反映生产环境，以使结果尽可能有意义。虽然我们目前确实有这样的测试环境，但它的能力远不及生产系统，这些软件工程师觉得他们已经达到了他们可以从中学习到的极限。

争论的另一端是一些网络工程师，他们既管理环境又控制钱包。虽然他们承认在更好地复制生产环境的环境中进行容量测试会更好，但他们认为——出于压力测试的目的——更适度的环境会放大性能瓶颈，使它们更容易发现和修复。

这最终将我们带到了引起我兴趣的部分：一位软件工程师建议，虽然压力环境更温和会增加您遇到瓶颈的可能性，但这并不一定意味着它会帮助您找到下一个瓶颈。在生产中遇到。他认为，规模效应可能不是线性的。

这种观点有道理吗？如果是，那为什么？这种非线性的根源是什么？

这里涉及很多活动部分：Java 应用程序服务器集群、数据库服务器集群、每次 HTTP 命中都会生成大量动态内容。

编辑：到目前为止，我很欣赏每个人的想法，但我真的希望有人能做的不仅仅是重新肯定一方，而是真正解决“为什么”的问题。如果存在这样的非线性，是什么导致了它？更好的是，如果用 CPU、内存、带宽、延迟、子系统之间的交互、你有什么来表达原因，那就太好了……TerryE，你最接近了。如果没有其他人站出来，您应该重新发布您的评论作为赏金的答案

4

6 回答 6

7

您的软件开发人员是对的，我将进一步说明这一点。

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

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

当您在环境上运行压力测试时，您可以测量该环境在负载下的行为及其瓶颈。虽然此测试可能会提供有价值的信息，但此信息与您的生产系统无关。您发现的瓶颈可能与您的实际系统无关，您可能会花费宝贵的开发时间来修复不存在的错误。要了解您真正可能面临的瓶颈，您应该在您的真实生产系统上运行压力测试（最好在盛大开幕之前）。

于 2012-10-23T13:35:43.590 回答
5

网络工程师的假设是，适度系统基本上是生产系统的比例模型。他们还假设将影响软件性能的生产环境的各种特征反映在更适度的系统中，只是在较低级别但以相同的比率。例如，CPU 没有那么快，内存没有那么多，存储有点慢，等等。所有这些差异的比例都相似，如果一切都神奇地乘以某个因子，比如 1.77，由此产生的变化的适度系统将与生产系统完全相同。

然而，在生产系统的所有细节中，这个适度的系统都是一个精确的比例模型，这让我很难相信。

这是一个具体的例子。假设生产系统上的测量表明 CPU 利用率（CPU 非空闲时间的百分比）太高。因此，您将软件放在普通系统上并进行测量，发现在普通系统上，CPU 利用率较低。一项调查显示，普通系统的存储速度较慢，因此 CPU 花费更多时间空闲等待数据从存储传输到完成，因为应用程序在普通系统上是 I/O 绑定的，而在生产系统上则不是。这种差异是由于普通机器不是生产机器的精确比例模型，因为 CPU 比率与 I/O 传输比率不同。

另一个例子是拥有更多内存，从而在生产环境中减少页面错误。当软件加载到更普通的机器上时，由于物理内存较少，会出现更多的页面错误。随着各种应用程序的调入和调出，它们开始相互影响，因为其他应用程序的页面被换出然后再次换入。在具有较大内存的产品机器上，这种级联缺页行为不会出现，因为有足够的内存来同时容纳更多的应用程序。

我在这里真正想要说明的一点是，一台具有各种部件和应用程序的计算机是一个复杂的动态系统。一个计算环境只是另一个计算环境的比例模型的想法过于简单化了一个假设。使用适度的系统当然可以提供有价值的数据。但是，一旦对软件进行了总体调整并且您开始进行更细微的详细调整，环境中的差异会对测试结果产生很大影响。

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

Uri Lerner、Ronald Parr、Daphne Koller 和 Gautam Biswas在动态系统中的贝叶斯故障检测和诊断。

于 2012-10-30T22:51:42.400 回答
5

我在生产环境中也遇到过类似的情况。我们仅将适度的系统用于初始和基本级别的测试和发现。确实，您永远无法在测试环境中找到真正的瓶颈和其他性能问题。因此，要找到真正的性能相关问题并找到瓶颈，您必须在生产环境中进行，没有其他方法。

我们已经托管了超过 250 万个网站，尽管您的网站可能并非如此，但让我告诉您，在我们的案例中，我们面临着可怕的线性瓶颈情况。这意味着，当我们的流量增加时，我们首先遇到了内存问题。我们通过添加更多内存解决了这个问题。在那之前，我们甚至没有注意到只有 256 个 httpd 线程是我们的下一个瓶颈，因为有限的内存隐藏了它，一旦我们解决了内存问题，它很快就归结为为什么我们的网络服务器在几周后又变慢了？我们发现 256 个 httpd 线程不足以提供这么多的流量。我们不仅增加了线程，还在我们的 WebServer 前安装了 HA 并行负载均衡器以缓解这个问题。

幸运的是，它解决了我们页面加载缓慢的问题。但是几个月后，随着流量的不断增长，我们进入了存储系统的下一个瓶颈。您知道这次磁盘 I/O 是什么问题。简而言之，我们放置了基于并行 NFS 的物理存储系统。现在，每台 NFS 机器通过运行超过 2000 个线程来提供文件。

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

我提到这一切只是为了证明一点，所有与性能相关的问题很可能几乎都是以线性方式出现的，至少这是我们在基于 Web 的模型中面临的问题。即使你在你的普通系统上进行了很多测试，你仍然有机会在测试环境中找不到隐藏的瓶颈。

我在过去 6 年的经验中学到了什么，如果您认为自己可能会有大量的流量或点击/秒，请尝试尽可能多地分发您的模型。集中式模型可以通过进行大量调整来保持您的流量一段时间，但最终您的系统会被破坏。

我并不是说你会在你的情况下面临一些瓶颈或问题，但我只是想警告你，这些情况有时会发生，只是为了让你更好地意识到。

**对不起我的英语不好。

于 2012-10-31T16:27:34.723 回答
2

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

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

如果你有数字，那么你不需要确切的测试结果。你只需要知道数量级。您还应该检查您的软件/硬件如何扩展。您需要处理多少个实例来处理 x 个用户/请求/什么，以及有多少个来处理 y

于 2012-10-22T20:24:04.580 回答
2

我们每天都在为我们的客户加载测试系统——我们看到了各种各样的问题。某些类型的问题可以在小型系统上找到。其他不能。有些只能在生产环境中找到……因为无论您多么密切地镜像这两个系统，它们都永远不会相同。如果你足够努力，你可以非常接近。

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

IMO，这是迁移到云的最佳理由之一：您可以启动一个非常接近您的生产系统的系统（几乎与您所能获得的相同）并在其上运行负载测试。

值得一提的是，我们偶尔会看到客户在他们的测试环境中浪费大量时间来解决在生产中永远不会发生的问题。环境越不同，发生这种情况的可能性就越大:(

于 2012-10-24T15:23:16.160 回答
2

我认为您已经部分回答了您自己的问题 - 您已经拥有一个生产级环境，并且已经发现它与生产环境不在同一级别/能力不强。底线是，用世界上所有的钱，你将永远无法复制生产网站的确切功能——事件的时间、容量、cpu 利用率、内存利用率、db IO，当一切都在激怒行为时在一定程度上可以是不确定的。我的观点是你永远不能让它完全一样。另一方面，生产环境本质上将是一个昂贵的环境，其中包含大量工具包，以使其执行和处理您的生产数据/交易量。这对企业来说是一笔很大的开支/开销，

也许应该采取不同的策略——了解你的生产软件的性能概况——它如何随容量扩展，运行时间是线性增加、指数增加还是对数增加？你能模拟这个吗？首先，您可以验证测试环境是否以类似的方式运行——这是进行有效测试的关键。然后另一个重要部分是进行相对测试而不是绝对测试 - 您不会获得与生产相同的绝对运行时间，而是在部署代码更改之前运行性能测试以提供基线，然后部署您的代码更改并重新运行性能测试 - 这将为您提供生产中的相对更改（例如，此代码版本会降低性能），

所以我的观点是，您可以在较低的环境中了解很多关于您的软件和硬件性能的信息，并且在较小/功能较弱的基础架构上执行此操作可以为您的公司节省资金，如果使用得当，可以为您提供大部分答案到您正在寻找的性能测试。

于 2012-10-26T21:48:43.600 回答