nodejs REST Api的端到端分析答案

【问题标题】：End to end profiling of nodejs REST Apinodejs REST Api的端到端分析
【发布时间】：2018-02-19 17:31:45
【问题描述】：

我编写了一个 Nodejs api，它将使用 5000 个并发请求进行访问。我已经使用 Jmeter 为 5000 个并发用户测试了 api。该 api 最初花费的时间很少，但在 1000 个请求之后，完成请求需要 2 秒。 api代码执行时间为400ms，按请求开始和结束的时间差计算。

有没有一种方法可以检查 API 请求在事件循环中等待其他请求完成的时间？有什么工具可以帮助对 API 进行端到端分析？

【问题讨论】：

我不明白这是什么意思：“Api 请求在事件循环中花费了多少时间等待其他请求完成”？
如果有大量并发请求，基本上我想找出阻塞事件循环或减慢 API 的代码块。那么有没有什么工具可以帮助我弄清楚 API 的完整跟踪和分析？目前托管代码的机器是具有 8GB RAM 的四核，我正在使用节点集群模块在所有内核中运行代码。所以 5000 个并发请求应该不是问题？
这完全取决于每个请求需要多少 CPU 时间，您是否可以在不增加延迟的情况下处理 5000 个并发请求，以及您是否对可能成为瓶颈的数据进行任何共享访问，而不管 CPU .我以前看过一些这样的工具来帮助描述这一点，但没有名字。仅供参考，仅要求 3rd 方工具在这里被认为是题外话。

标签： javascript node.js profiling v8

【解决方案1】：

Node.js 支持使用 --prof 标志进行分析，参见例如https://nodejs.org/en/docs/guides/simple-profiling/（以及互联网上的许多其他文档和教程）。这并没有回答“这个特定请求做了什么或等待了什么？”，但它确实回答了“节点进程花时间在做什么？” -- 希望这两个问题都有相同的答案。

除此之外，我建议您简化设置以缩小发生的范围。如果您只在一个核心上运行（请求较少），问题是否仍然存在？如果减少并发请求的数量，问题是否仍然存在？在极端情况下，如果您串行发送请求，问题是否仍然存在？你越能简化事情，你就越容易知道发生了什么。

可能是您的实现泄漏了一些资源（内存、文件处理程序等），随着时间的推移使事情变得更慢。可能是 5000 个并发请求超出了您的四核处理能力。

【讨论】：