optimization - 在功能较弱的硬件上对 Web 应用程序进行压力测试

Question

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

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

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

争论的另一边是一些网络工程师，他们既管理环境又控制钱包。虽然他们承认在生产环境的更好副本的环境中进行容量测试会更好，但他们认为 - 出于压力测试的目的 - 一个更温和的环境将具有放大性能瓶颈的效果，使它们更容易发现并修复。

这最终让我们想到了激起我兴趣的部分:一位软件工程师建议，虽然更适度的压力环境会增加您遇到某些瓶颈的可能性，但这并不一定会帮助您找到下一个可能遇到的瓶颈生产中遇到。他认为，规模效应可能不是线性的。

这种观点有什么可取之处吗？如果是，那为什么？这种非线性的来源是什么？

这里涉及到很多事件部分:Java 应用程序服务器集群、数据库服务器集群、为每个 HTTP 命中生成的大量动态内容。

编辑:到目前为止，我感谢每个人的想法，但我真的希望有人能做更多的事情，而不是重新肯定一方或另一方，并实际解决“为什么”的问题。如果存在这种非线性，是什么导致了它？更好的是，如果将原因表达为 CPU、内存、带宽、延迟、子系统之间的交互，你有什么...... TerryE，你离得最近。如果没有其他人站出来，您应该重新发布您的评论作为赏金的答案

Answer 1

你的软件开发人员是对的，我会更进一步。

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

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

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