问为什么JMeter与网站运行在同一台机器上很重要？

EN

为了避免相互干扰，在不同的主机上运行JMeter和应用程序要好得多。理论上，你可以把它们放在同一台机器上，但结果并不可靠。

负载测试不仅仅是获取主要指标和KPI(如响应时间、每秒事务、吞吐量等)--在测试结果分析过程中需要考虑许多其他信息才能找到性能问题的根源。

例如，您对平均响应时间不满意。申请速度慢的原因可能是：

• 耗尽CPU/RAM/网络或磁盘IO。所以你才会
  • 不应该让JMeter在同一台主机上运行
  • 应该考虑健康测试下的监测应用

• “坏”应用程序/web/数据库服务器配置。所有这些组件(顺便说一下，包括JMeter )都具有非常低的默认值，这些值对于开发和/或调试都很好，但对于负载测试或生产绝对不够。
• 网络问题。如果您观察到较高的连接或延迟值-网络是一个瓶颈。您将永远不会看到在同一台机器上部署了测试JMeter和应用程序。
• 被测试的应用程序代码质量差。在这种情况下，您需要使用剖面分析工具来识别最“饥饿”的应用程序部分并标记它们

答案--简略

严格推荐的方法:在远程服务器上执行JMeter脚本。

原因: JMeter占用大量内存，影响机器性能，因此在同一台服务器上执行JMeter脚本会产生错误报告。

就增加响应时间而言，网络是成本最高的资源。当您在与web服务器相同的服务器上运行时，您正在系统总线上处理请求和响应，这比收集客户端的网络快一个数量级。您还正在塑造服务器的性能曲线，以处理测试工具的执行和响应所带来的额外负载。在主机上的生产中，负载的执行不会出现。

当您考虑CPU、磁盘、内存和网络的有限资源模型时，与生产相比，在同一服务器上作为目标的负载的分期会对CPU、磁盘和内存的有限资源池产生负面影响，并将最昂贵的资源网络的影响降到最低。

因此，从暂存角度和与生产目标配置匹配的角度来看，这将导致审计失败。顺便说一下，这更多的是一个过程问题，而不是一个工具问题。