我在使用JMeter进行性能测试时遇到了一个特殊的问题，我可以使用一些指导来解决这个问题。
**背景：**我们有一个API，最近我们引入了一个新的API，可以将多个调用聚集到一个调用中。旧的API需要多个POST和GET请求才能实现相同的结果，而新的API通过发出一个内部调用旧API的POST请求来简化这一点。令人惊讶的是，在性能测试期间，我们观察到新的API比旧的API快得多，即使它依赖于相同的底层调用。
**问题：**旧API中的一个GET请求在JMeter负载测试期间花费的时间比预期长得多，这导致新旧API之间的性能差异。我们正在试图理解为什么这个特定的GET请求比预期的要长。
检查新API中的缓存机制检查两个API的响应数据比较两个API的请求
1条答案
按热度按时间h5qlskok1#
在不知道“新API”实现细节的情况下，不可能提供全面的答案，可能会运行对“旧API”in parallel的调用，然后聚合响应，可能会保持connection pool打开，而不是单独建立与每个服务的连接，如果数据相对“新鲜”，则可能是caches流行响应并且不进行实际请求的情况。
因此，您需要确保JMeter测试的网络足迹与“新API”产生的网络足迹相同，并相应地设置JMeter的线程组和HTTP请求采样器。
关于单个服务花费的时间比预期的长-使用分析器工具检查引擎盖下发生了什么，identify the bottleneck并修复它。