1.我们有一个开放的芬兰应用程序托管在美国服务器上。2.我们使用Jmeter来获得不同模块的性能，如登录注销时间。3.在记录和运行包含所有嵌入元素的jmter测试计划时，我们获得的时间与手动性能结果相似。4.但是，当我们在托管应用程序的服务器上破坏相同的测试计划时，结果太快了，并且与我们在服务器上获得的手动性能数据不同。
现在很难判断哪些数据是正确的，哪些不是。- 上面提到的方法是否正确，以及如何在服务器和本地机器上获得与手动性能同步的结果。
Local Machine ResultsServer Data
当我们手动运行应用程序并注意本地机器和服务器上的时间时，它们几乎相似。
但是在运行JMeter时，结果会有很大的不同。
期望在本地机器和服务器上获得相同的手册和JMeter数据。
我已经应用了所有的头管理器、缓存管理器和动态正则表达式，使其更接近于真实的客户端模拟。
2条答案
按热度按时间vs3odd8k1#
设想一个场景，您正在从本地机器加载数据。在这种情况下，你实际上是在广阔的互联网上发送一个请求，穿越你办公室或家庭网络的复杂网络。这个旅程涉及许多“跳”，或中间点，在它最终到达它的预定目的地-服务器。
现在，考虑另一个场景，您从应用程序所在的环境中发送请求。这种方法使您更接近服务器，大大减少了请求需要覆盖的距离。当然，这种接近程度最终取决于端点的性质--它是网络拓扑中的内部节点还是外部节点。这种区别至关重要，因为它决定了处理您的请求的效率和速度。
干杯！干杯！
bybem2ql2#
让我用简单的话重新表述一下：
1.您从您所在的位置运行了JMeter测试，并获得了结果1
1.您从您所在的位置使用浏览器运行了手动测试并获得了结果2
1.你比较了结果1和结果2，它们是相似的
1.您从靠近被测系统的位置运行了一个JMeter测试，并得到了结果3
1.现在你问为什么结果3不同于结果1和2。难道您不应该从靠近被测系统的位置运行您的“手动测试”吗？
此外，仅查看响应时间并不能说明全部情况，还可以考虑分析Connect Time和Latency。
一般来说，对于查找应用程序缺陷来说，负载生成器位于何处以及请求到达服务器和响应通过线路返回需要多长时间并不重要，这个时间或多或少是相同的，您可以通过从经过时间中减去延迟来获得它。
服务器处理时间是您需要的，在特定阈值之后，它将随着负载的增加而增加。
如果应用程序所有者希望应用程序在亚洲或澳大利亚快速响应，他应该考虑将示例部署在更靠近最终用户的位置，并根据用户IP地址将流量路由到这个或那个示例。
有关指标、指标的含义以及如何分析指标的更多信息：