我使用JMeter通过使用OS Samplers来测试我们的后端服务。我在OS采样器中使用CURL来生成4步过程的负载。
我面临的问题是JMeter报告的响应时间比服务日志高得多。我们需要确定在事务执行期间额外时间（带有1个并发用户的+125 ms）的来源。测试环境全部位于同一VLAN中，两个客户端和目标服务器之间没有防火墙或代理服务器。两台服务器之间的中间延迟为0.3毫秒，平均值为1.2毫秒（样本量较小）。在与开发团队交谈时，他们声明服务日志不会在收到请求的第一时刻记录，但无法看到它如何不仅仅是几毫秒的差异。来自少数测试的数据增加了吞吐量并且开销大致保持不变，这与该假设是一致的。
所以我们专注于看看JMeter是否会造成额外的开销。一个假设是JMeter在开始生成CURL请求时开始交易时间，并且请求的打包包含在此时间中。因此，我们希望从测试中删除CURL OS Sampler并将其替换为HTTP Sampler。
将JMeter OS Sampler CURL请求转换为HTTP Sampler HTTPS请求时，我们遇到错误JMeter：非HTTP响应消息：拒绝连接到URL。如上所述，我们首先发布证书，发布令牌，然后发布步骤3和4.当从第一步发布获取的令牌时，HTTP Sampler在第二步失败。我们通过继续出错并处理第二步原始CURL POST请求来验证获取的令牌是好的。所以这里有两件事。 1.错误消息表明它从未完成握手，因此它没有到达处理消息的程度。 2.使用相同信息的以下CURL请求完成握手并正确处理事务。
转换归结为＆＃34;为什么发送OS Sampler CURL命令并且HTTP Sampler无法完成握手？
OS Sampler CURL命令配置为：
HTTP Sampler配置为：
答案 0 :(得分：1)
您的帖子中有两个单独的问题。关于第一个：
您如何衡量服务器之间的延迟？如果您正在使用ping，则需要测量1次发送和接收的往返时间。 HTTP POST通常不仅包括TCP来回握手，然后发送内容 - 这又取决于大小可以分成几个数据包 - HTTP响应通常比请求大。与简单的ping相比，对于较大的有效载荷分组，延迟也可能稍微高一点。
这可能无法解释您所看到的整体差异（就像您已经注意到的，其中一些来自启动卷曲的延迟），但仍然会导致整体延迟增加。您应该使用某种类型的网络分析器，至少是像WireShark这样的嗅探器，以了解您正在使用的每个HTTP步骤的干扰或来回数量。