我的组织现在正在进行一场有趣的内部辩论，这引发了一个我想向整个社区开放的问题。
手头的问题是我们在环境中进行压力测试，容量测试，性能回归测试等。
争论的一方面是一些软件工程师希望这个环境尽可能地反映生产环境，以使结果尽可能有意义。虽然我们目前确实有这样的测试环境，但它的能力远远低于生产系统，而且这些软件工程师认为他们正在达到他们可以从中学到的极限。
争论的另一方面是一些管理环境和控制钱包的网络工程师。虽然他们承认在能够更好地复制生产环境的环境中容量测试会更好，但他们认为 - 为了压力测试的目的 - 更温和的环境会产生放大性能瓶颈的影响，使它们更容易发现和修复。
这最终将我们带到引起我兴趣的部分：一位软件工程师建议，虽然更适度的压力环境会增加您遇到某些瓶颈的可能性，但它不会必然会有助于您找到生产中可能遇到的下一个瓶颈。他认为，缩放效应可能不是线性的。
这种观点是否有价值？如果是，那为什么呢？这种非线性的来源是什么？
这里涉及许多活动部分：一组java应用程序服务器，一组数据库服务器，为每次HTTP命中生成大量动态内容。
编辑：到目前为止，我很欣赏每个人的想法，但我真的希望有人能做的不仅仅是重新确认一方或另一方，而是切实解决“为什么”的问题。如果存在这种非线性，会产生什么？更好的是，如果原因表现在CPU，内存，带宽，延迟，子系统之间的交互，你有什么...... TerryE，你来的最近。如果没有其他人加强，您应该重新发布您的评论作为赏金的答案
答案 0 :(得分：7)
您的软件开发人员是对的，我会更进一步。
当您测试应用程序组件（如Web服务）以查看其在负载下的行为时，使用功能较弱的环境是可以理解的。你可以找到关于内存，io等的瓶颈。而且很可能会发现内存错误和日志文件变得越来越大的bug和疏忽。
但是当您的应用程序组件按预期运行并且您需要测试整个shebang时，您需要测试真实环境。
当您在环境中运行压力测试时，您可以测量该环境在负载下的行为及其瓶颈。虽然此测试可能提供有价值的信息，但此信息不会与您的生产系统有关。您找到的瓶颈可能与您的真实系统无关，您可能花费宝贵的开发时间来修复不存在的错误。要了解您可能面临的瓶颈，您应该在您的真实生产系统上进行压力测试（最好在盛大开幕之前）。
答案 1 :(得分：5)
网络工程师的假设是，适度的系统基本上是生产系统的比例模型。他们还假设生产环境的各种特性会影响软件性能，只是在较低的水平，但是在相同的比率下才会反映在更适度的系统中。例如，CPU不是那么快，没有那么多的内存，存储速度有点慢等等，并且所有这些差异都是相似的比例，这样如果一切都神奇地乘以一些因素，比如1.77，由此产生的改变后的适度系统将与生产系统完全相同。
然而，对于生产系统的所有细节而言，适度的系统是精确的比例模型，我很难相信。
这是一个具体的例子。可以说生产系统上的测量结果表明CPU利用率（CPU没有空闲的时间百分比）太高。因此，您将软件放在适度的系统上并进行测量，并发现在适度的系统上，CPU利用率较低。调查显示，适度的系统存储速度较慢，因此CPU花费更多的时间等待从存储到完成的数据传输，因为应用程序是I / O绑定在适当的系统上，而生产系统则不是。这种差异是由于适度的机器不是生产机器的精确比例模型，因为CPU比率不同于I / O传输比率。
另一个例子是拥有更多内存，允许生产环境中更少的页面错误。当软件加载到更适度的机器上时，由于物理内存较少，会出现更多页面错误。随着各种应用程序分页进出，它们开始相互影响，因为其他应用程序的页面被换出然后再次交换回来。在具有更大内存的产品计算机上，由于有足够的内存来同时容纳更多应用程序，因此无法看到此级联页面错误行为。
我真正想要做的是，拥有各种各样部件和应用程序的计算机是一个复杂的动态系统。一个计算环境只是另一个计算环境的比例模型的想法过于简单化了。使用适度的系统当然可以提供有价值的数据。但是，一旦对软件进行了大量调整，并且您开始进行更细微的详细调整，环境的差异就会对测试结果产生很大影响。
一些引用。 Computer systems are dynamical systems来自Tod Mytkowicz，Amer Diwan和Elizabeth Bradley。
Uri Lerner，Ronald Parr，Daphne Koller和Gautam Biswas答案 2 :(得分：5)
我在生产环境中遇到过类似的情况。我们仅使用适度的系统进行初始和基本级别的测试和发现。确实，您永远无法在测试环境中找到真正的瓶颈和其他性能问题。因此，要找到真正的性能相关问题并找到瓶颈，你必须在生产环境中做到这一点，没有别的办法。
我们已经托管了超过250万个网站，虽然可能不属于您的网站，但让我告诉您，在我们的案例中，我们遇到了线性瓶颈的可怕情况。这意味着，当我们的流量增加时，我们首先遇到内存问题。我们通过添加更多内存解决了这个问在那之前，我们甚至没有注意到只有256个httpd线程是我们的下一个瓶颈，因为有限的内存隐藏了它，一旦我们解决了内存问题，它很快就会解决为什么我们的网络服务器在几周之后再次变慢的问题？我们发现256个httpd线程不足以为这么多流量提供服务。我们不仅增加了线程，还在WebServers前面安装了HA并行负载平衡器，以缓解此问题。
幸运的是，它解决了我们的慢页加载问题。但随着流量持续增长几个月，我们陷入了存储系统的下一个瓶颈。你知道这次磁盘I / O是什么问题。为了简化故事，我们提出了基于NFS的并行物理存储系统。现在，每台NFS计算机都运行超过2000个线程来提供文件。
我忘了提到数据库也是一个缓慢的罪魁祸首，我们通过在集群中安装Master-Slaves模型解决了这个问题。我们还必须在应用程序代码中进行大量的性能调整，并且我们必须将应用程序物理地分发到不同服务器上的不同模块中。
我只是提到所有这些，以证明所有与性能相关的问题很可能几乎以线性方式出现，至少这是我们在WebBased模型中遇到的问题。即使您已经在适度的系统上进行了大量测试，您仍然有机会隐藏在测试环境中无法找到的瓶颈。
我在过去6年的经验中学到了如果您认为自己可能会有很多流量或点击/秒，那么尝试分发您的模型是非常可能的。集中模型可以通过多次调整来保持您的流量一段时间，但最终系统会被破坏。
我并不是说你的情况会遇到一些瓶颈或问题，但我只是想警告你，这些情况有时会发生，只是让你们更清楚。
**抱歉我的英文。
答案 3 :(得分：2)
如果你有数字，那么你不需要精确的测试结果。你只需知道数量级。您还应该检查您的软件/硬件规模。您需要处理x个用户/请求/处理y
的任何和多少个实例答案 4 :(得分：2)
我们每天为客户加载测试系统 - 我们会发现各种各样的问题。在缩小尺寸的系统上可以找到某些类型的问题。其他不能。有些只能在生产中找到...因为无论你如何密切地镜像这两个系统，它们永远不会是相同的。如果你努力工作，你可以真正关闭。
因此，简单的测试事实：您的系统越接近生产系统，您的测试就越准确。
IMO，这是迁移到云的最佳理由之一：您可以启动一个非常接近您的生产系统的系统（大致与您可能获得的相同）并对其进行负载测试。
值得一提的是，我们偶尔会看到客户在测试环境中浪费了大量时间来追逐生产过程中从未发生过的问题。环境越不同，就越有可能发生这种情况:(
答案 5 :(得分：2)
我认为您已经部分回答了自己的问题 - 您已经拥有一个生产级环境，并且已经发现它与生产环境不同，不具备相同的能力。最重要的是，凭借世界上所有资金，您将永远无法复制生产网站的确切功能 - 事件，数量，CPU利用率，内存利用率，数据库IO的时间，当它们全都在愤怒地工作时在某种程度上可能是不确定的。我的观点是你永远不能完全一样。而在硬币的另一面，生产环境本质上将是一个昂贵的环境，有很多工具包，以使其执行和处理您的数据/交易的生产量。这对企业来说是一笔巨大的开支/开销，在这些节俭的时候，我们不应该考虑避免额外的业务成本。
也许应该采取不同的策略 - 了解生产软件的性能配置文件 - 它如何随体积缩放，运行时间是线性增加，指数增长还是对数增长？你能模仿这个吗？首先，您可以验证测试环境的行为方式类似 - 这是进行有效测试的关键。然后另一个重要的部分是进行相对测试而不是绝对测试 - 你不会获得与生产相同的绝对运行时间，而是在部署代码更改之前运行性能测试以获得基线，然后部署代码更改并重新运行性能测试 - 这将为您提供生产中的相对更改（例如，此代码版本的性能会降低），根据您的性能模型，您将能够验证软件是否在同一个版本中进行扩展额外音量的方式。
所以我的观点是，您可以在较低的环境中了解有关软件和硬件性能的大量信息，并且在较小/功能较弱的基础架构上执行此操作可以节省公司资金，如果使用得当可以为您提供最大的支持您正在寻找的性能测试答案。