【问题标题】:JMeter: Non HTTP response message: Connection to URL refusedJMeter:非 HTTP 响应消息:连接到 URL 被拒绝
【发布时间】:2015-09-15 14:49:07
【问题描述】:

我正在使用 JMeter 通过 OS Samplers 测试我们的后端服务。我在 OS 采样器中使用 CURL 来生成 4 步过程的负载。

  1. 发布证书以接收令牌
  2. POST 令牌以接收会话
  3. 获取会话信息
  4. POST 更新会话

我面临的问题是 JMeter 报告的响应时间比服务日志高得多。我们需要确定在事务执行期间额外时间(1 个并发用户 +125 毫秒)来自何处。测试环境都在同一个 VLAN 上,两个客户端和目标服务器之间没有防火墙或代理服务器。两台服务器之间的中位延迟为 0.3 毫秒,平均值为 1.2 毫秒(样本量较小)。在与开发团队交谈时,他们表示服务日志不会在收到请求的第一时间记录下来,但看不出它可能只是几毫秒的差异。来自一些增加吞吐量和开销大致保持不变的测试的数据将与该假设一致。

所以我们现在专注于查看 JMeter 是否导致了额外的开销。一个假设是,JMeter 在开始生成 CURL 请求时开始事务时间,并且请求的打包包含在此时间中。所以我们想从测试中删除 CURL OS 采样器并用 HTTP 采样器替换它。

在将 JMeter OS Sampler CURL 请求转换为 HTTP Sampler HTTPS 请求时,我们遇到了错误 JMeter: Non HTTP response message: Connection to URL denied。如上所述,我们首先发布证书,发布令牌,然后是步骤 3 和 4。在发布从第一步获取的令牌时,HTTP 采样器在第二步失败。我们已经通过继续出错并处理第二步原始 CURL POST 请求来验证获取的令牌是好的。所以这里有两件事。 1.错误消息说它永远不会完成握手,所以它没有到达处理消息的地步。 2. 以下使用相同信息的 CURL 请求完成握手并正确处理事务。

进行转换归结为“为什么发送 OS Sampler CURL 命令会完成而 HTTP Sampler 无法完成握手?

OS Sampler CURL 命令配置为:

  • curl -k -d "" -v -H "{token}" {URL}

HTTP Sampler 配置为:

  • IP:{URL}
  • 端口:{端口#}
  • 实现:HttpClient4
  • 协议:HTTPS
  • 方法:POST
  • 路径:{路径}
  • 使用 KeepAlive:检查
  • 标头管理器:{token}

【问题讨论】:

  • 如果没有 -k 选项,你的 curl 是否工作?

标签: ssl curl service jmeter performance-testing


【解决方案1】:

您的帖子中有两个单独的问题。关于第一个:

您如何测量服务器之间的延迟?如果您使用 ping,则您正在测量 1 次发送和接收的往返时间。 HTTP POST 通常不仅仅是包括 TCP 来回握手然后发送内容 - 再次取决于大小可以拆分为多个数据包 - HTTP 响应通常大于请求。与简单的 ping 相比,对于较大的有效负载数据包,延迟也可能会稍高一些。

这可能无法解释您所看到的全部差异(正如您所指出的,其中一些来自启动 curl 的延迟),但仍然会导致整体延迟增加。您应该使用某种网络分析器,至少是像 WireShark 这样的嗅探器来了解您正在使用的每个 HTTP 步骤的闲聊或来回次数。

【讨论】:

  • 感谢 RaGe 的回复。是的,我们使用简单的 ping 来测量延迟,我完全同意,与服务请求相比,我们的服务请求中发送的内容大于 ping 所考虑的内容。这些请求很小,因为它们只是身份验证请求,因此我们此时并不十分担心网络延迟。我们将在服务日志中看到服务请求处理 5 到 10 毫秒,但 JMeter Rt 记录为 150 到 350 毫秒。我想弄清楚是我们的记录测量点还是测试工具测量。
  • 我建议使用带有 -w 选项的 curl 并写出每个 HTTP 操作的连接、传输和总时间。这将有助于消除 JMeter 或网络作为嫌疑人。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-07-05
  • 2017-01-25
  • 2017-12-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多