【问题标题】:2 minute latency on random POST or PUT requests随机 POST 或 PUT 请求延迟 2 分钟
【发布时间】:2015-11-30 16:54:21
【问题描述】:

我向 Node.js HTTPS 服务器发出的大约 10% 的 POST 或 PUT 请求需要 2 分钟才能得到响应。其他 90% 的行为符合预期。

我已经用 tshark 验证了请求的正文被服务器接收到了,但是之后需要 2 分钟才能触发 ServerRequest 对象的 'data' 和 'end' 事件。

经历这种延迟的请求似乎是随机的,但当它确实发生时,接收数据包与触发“数据”和“结束”事件之间的延迟时间总是正好 2 分钟。

对于所有这些请求,我发布了一个以单个数据包形式到达的小型 json 对象。对于遇到延迟的请求,我知道我的应用程序收到了标头,因为会话 cookie 会立即被解析。在会话身份验证之后,直到 2 分钟后最终发出 'data' 和 'end' 事件之前什么都没有发生,此时正文被解析并保存到我的数据库中。

这更有可能是我的 Node 应用程序的问题,还是我的服务器(运行 Amazon Linux 的 EC2 小型实例)的问题?从带有请求正文的数据包到达到它作为一个块传递给我的应用程序需要 2 分钟,这是怎么回事?

谢谢。

更新: 我修改了 lib/http.js 中的 parser.onBody 以记录“b”,我可以看到直到两分钟延迟结束才调用此方法。这似乎表明问题比我的应用程序低。我还更改了 ec2 实例,但这没有帮助。

【问题讨论】:

  • 2分钟一致吗?对这些请求做了多少工作?有没有可能与垃圾收集有关? stackoverflow.com/questions/5603011/…
  • 是的,每次正好两分钟。没有太多工作——我附加了一个解析的 url,解析了会话 cookie 并从 redis 附加了一个会话对象。我从未见过任何延误。我不认为这是垃圾收集,因为当一个被卡住时,我可以继续正常接收其他帖子请求。

标签: node.js amazon-ec2


【解决方案1】:

如果不确切知道节点应用程序对每个请求做了什么,就很难说。例如,如果它必须与另一个后端服务通信,这与仅从内存中的缓存中提供图像有很大不同。

话虽如此,EC2 小实例可能非常有气质。它们与其他客户大量共享,因此有时它们会变得奇怪地没有反应。感受这一点的一种方法是在 EC2 实例的命令行中运行“top”。查找列 %st,它是窃取。如果高,那就不好了,切换到一个新的 EC2 实例。 (或者买一个更大的)

【讨论】:

    【解决方案2】:

    我只是在验证后才监听“数据”事件。我在验证后的回调中有req.on('data', function(chunk) {req.body += chunk});,而不是在主监听器函数中。通常有效载荷在我开始监听之前就已经到达了。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-09-10
      • 1970-01-01
      • 2017-08-10
      • 1970-01-01
      • 1970-01-01
      • 2015-01-07
      相关资源
      最近更新 更多