我的组织正在进行一个有趣的内部辩论，这提出了一个我想向社区开放的问题。
手头的问题是我们进行压力测试，能力测试，性能回归测试等的环境。
在辩论的一侧是一些软件工程师，他们希望这种环境尽可能地反映生产环境，以使结果尽可能有意义。虽然我们目前确实有一个用于此类测试的环境，但它的能力远不如生产系统，这些软件工程师认为他们正在达到他们可以从中学到的东西的极限。
辩论的另一侧是一些网络工程师，他们既管理环境又控制钱包串。尽管他们承认在一个更好的生产环境的环境中，容量测试会更好，但他们认为 - 出于压力测试的目的，更适度的环境将产生放大性能瓶颈的影响，从而使它们更容易发现和修复。
这最终使我们引起了我的兴趣：一位软件工程师建议，虽然更适中的压力环境会增加您遇到的可能性某种瓶颈的可能性，但它不会一定要遵循，它将帮助您找到您在生产中可能遇到的下一个瓶颈。他认为，缩放效果可能不是线性的。
该观点是否有优点？如果是，那为什么？这种非线性的来源是什么？
这里涉及很多活动部件：一组Java应用程序服务器，一组数据库服务器，每个HTTP命中都会生成许多动态内容。
编辑：我感谢每个人到目前为止的想法，但是我真的希望有人会做更多的事情，而不仅仅是重新确认一侧或另一方，并实际上解决了"为什么"的问题。如果存在这样的非线性，什么引起了？更好的是，如果以CPU，内存，带宽，延迟，子系统之间的交互，您有什么样的原因来表达原因，那将是很棒的。如果没有其他人加强
您的软件开发人员是正确的，我应该将评论作为赏金的答案作为赏金的答案。
提出这一点当您测试应用程序组件（例如Web服务）以查看其在负载下的行为时，使用功能较低的环境是可以理解的。您可以找到有关内存，IO等的瓶颈，并且很可能会发现错误和监督，例如内存错误和日志文件变得巨大。
但是，当您的应用程序组件按预期运行并且需要测试整个Shebang时，您需要测试真实的环境。
当您在环境上进行压力测试时，您可以测量该环境在负载及其瓶颈下的行为。尽管该测试可能会提供有价值的信息，但此信息将与您的生产系统有关。您发现的瓶颈可能与您的真实系统无关，您可能会花费宝贵的时间来修复不存在的错误。要了解您真正可能面临的瓶颈，您应该在真实的生产系统上进行压力测试（最好是在开放之前）。
网络工程师的假设是，谦虚的系统基本上是生产系统的比例模型。他们还假设，生产环境的各种特征将影响软件性能，则在较低级别的较小级别中反映了相同的比率。例如，CPU的速度不那么快，内存不那么多，存储时间较慢，等等。所有这些差异的比例相似，以至于一切都被神奇地乘以某个因素，例如1.77，所得更改的适度系统就像生产系统一样。
然而，适度的系统是生产系统所有细节的确切规模模型，我很难相信。
这是一个具体示例。可以说，生产系统上的测量值表明CPU利用率（CPU的时间百分比不是闲置）太高。因此，您将软件放在适度的系统上，并进行测量，并发现在适度的系统上，CPU利用率较低。一项调查表明，适度的系统的存储空间较慢，因此CPU花费更多的时间闲置等待数据传输到"存储"到"完成"，因为应用程序是在适度的系统上绑定的，而在生产系统上，该应用程序却没有。这种差异是由于CPU比与I/O传输比不同，因此适度的机器不是生产计算机的确切比例模型。
。另一个示例是有更多内存，在生产环境中允许更少的页面故障。将软件加载到更适度的机器上时，由于物理内存较少，因此会有更多的页面故障。随着各种应用程序的分页，它们开始相互影响，因为其他应用程序的页面被交换了，然后再次交换回。在具有更大内存的产品计算机上，此级联页面故障行为没有看到，因为有足够的内存可以同时保存更多应用程序。
我真正想在这里提出的观点是，具有各种零件和应用程序的计算机是一个复杂的，动态的系统。一个计算环境只是另一个计算环境的比例模型的想法过于简单。使用适中的系统当然可以提供有价值的数据。但是，一旦对软件进行了总体调整，并且您开始进行更微妙的详细调整，环境的差异可能会对测试结果产生很大的影响。
一些引用。计算机系统是Tod Mytkowicz，Amer Diwan和Elizabeth Bradley的动态系统。
Uri Lerner，Ronald Parr，Daphne Koller和Gautam Biswas的动态系统中的贝叶斯故障检测和诊断。
我在生产环境中遇到了类似的情况。我们仅用于初始和基本级别的测试和发现。的确，您永远无法在测试环境中找到真正的瓶颈和其他性能问题。因此，要找到实际性能与绩效相关的问题并找到瓶颈，您必须在生产环境上做到这一点，没有其他方法。
我们已经托管了超过250万的网站，尽管您可能并非如此，但让我告诉您，在我们的情况下，我们面临着可怕的线性瓶颈情况。意思是，当我们的流量增加时，我们首先面临记忆问题。我们通过添加更多内存来解决这一问题。在那之前，我们甚至还没有注意到只有256个线程HTTPD是我们的下一个瓶颈，因为有限的内存隐藏了它，一旦我们解决了内存问题，它很快就会遇到一个问题，为什么我们的Webervers仅几周后我们的WebServers再次放慢速度？我们发现256个HTTPD线程还不足以提供太多的流量。我们不仅增加了线程，而且还在网络服务器前面安装了HA并行负载平衡器以减轻问题。
幸运的是，它解决了我们的慢页加载问题。但是随着交通不断增长，我们进入了下一个存储系统的瓶颈。您知道这次磁盘I/OS是问题所在。为了使故事简短，我们放置了基于NFS的物理存储系统。现在，每台NFS机器都通过运行2000多个线程来服务文件。
我忘了提到数据库也是我们通过在群集中安装主奴隶模型来解决该问题的巨大罪魁祸首。我们也必须在应用程序代码中进行大量的性能调整，我们必须将应用程序物理分配到不同服务器的不同模块中。
我只是提到所有这些，以证明所有与绩效相关的问题很可能几乎是线性的，至少这就是我们在基于Webbase的模型中所面临的。即使您在适度的系统上进行了很多测试，您仍然有机会隐藏的瓶颈，在测试环境中找不到。
我在过去6年的经验中所学到的东西尝试，如果您认为您可能会拥有很多流量或命中/秒，请尽可能多地分发您的模型。集中式模型可以通过进行大量调整来保持您的流量一段时间，但最终您的系统被破坏了。
我并不是说您会在您的情况下面临一些瓶颈或问题，但我只是想警告您这些情况有时会发生，只是您更好地意识到。
**对不起我的英语。
好问题。在适度的硬件上学习和优化是最好的。但是测试在镜子上更安全（或至少来自同一时期的东西）
它像您试图预测将出现的第一个瓶颈和何时发生的接缝。我不确定这是否是正确的目标和正确的方法。我认为我们不会谈论客户说"它应该像其他所有Web应用程序一样快"的典型CRUD。如果您想正确进行测试，则开始进行测试，您应该知道预期的负载。预期的用户数量，预期的事件数量，响应时间等。这是您产品规范的一部分。如果您没有数字，那意味着您的分析师没有完成工作。
如果您有数字，则不需要确切的测试结果。您只需要知道数量级。您还应该检查软件/硬件比例。您需要多少个实例来处理X用户/请求/任何处理y
我们每天为客户加载测试系统 - 我们看到了各种各样的问题。某些类别的问题可以在大小的系统上找到。其他不能。有些只能在生产中找到……因为无论您多么近距离镜像两个系统，它们永远都不相同。如果您努力工作，您可以真正接近。
因此，测试的简单事实：您的系统越接近生产系统，您的测试就越准确。
imo，这是转向云的最佳原因之一：您可以旋转一个非常接近生产系统（尽可能相同的系统）并对此进行负载测试。
可能值得一提的是，我们偶尔会看到客户浪费了很多小时来追逐他们的测试环境中，这些问题在生产中从未发生过。环境越不同，发生这种情况的可能性就越大：（
我认为您已经部分回答了自己的问题 - 您已经有一个生产级别的环境，并且已经发现它的水平与生产环境的水平不一样/没有能力。最重要的是，借助世界上所有的钱，您将永远无法复制生产网站的确切功能 - 事件，卷，CPU利用率，内存利用率，DB IO的时间，当它都在激怒行为时在一定的扩展方面可以是不确定性的。我的意思是您永远无法使其完全相同。在硬币的另一侧，生产环境本质上将是一个昂贵的环境，并具有很多套件，以使其执行并处理您的数据/交易的生产量。这是业务的巨大费用/开销，在节俭的时期，如果我们不想避免企业额外的费用。
也许应该采取不同的策略 - 了解生产软件的性能概况 - 它如何按音量扩展，运行时间是否线性，指数或对数增加？你能为此建模吗？首先，您可以验证测试环境的行为类似 - 这是进行有效测试的关键。然后，另一个重要的部分是进行相对测试而不是绝对测试 - 您不会获得与生产相同的绝对运行时间，而是在部署代码更改之前进行性能测试以给您基线，然后部署代码更改并重新运行性能测试 - 这将为您提供相对的生产变化（例如，根据您的性能模型，您将能够验证该软件在相同的范围中缩放的性能，而性能会降低此代码版本。带有额外音量的方式。
所以我的观点是，您可以在较低的环境中了解您的软件和硬件性能，并且在较小/功能较低的基础架构上进行此操作可以节省您的公司的钱，如果使用正确的话，可以为您提供最大的收益您正在寻找的性能测试的答案。