node.js - 使用 node.js 测量 http 请求时间

Question

我使用 node.js 发送 http 请求。我有一个需求来测量它花了多少时间。

start = getTime()
http.send(function(data) {end=getTime()})

如果我在 http 响应回调中调用 getTime，则存在由于队列中的其他事件导致响应返回时我的回调不会立即被调用的风险。如果我为此任务使用常规 java 或 c# 同步代码，也会存在这种风险，因为可能另一个线程在我之前得到了关注。

start = getTime()
http.send()
end=getTime()

node.js 与其他(同步)平台相比如何 - 它使我获得良好衡量标准的机会更好还是更差？

Answer 1

伟大的观察!

理论:

如果您正在执行微基准测试，则存在许多可能会影响测量结果的注意事项:

1. 事件循环中的其他事件已准备好与相关的 HTTP 发送一起触发，并在发送有机会之前按顺序执行 - 特定于 Node 。

2. 在发送操作范围内随时可能发生的线程/进程切换 - 通用。

3. 内核的 I/O 缓冲区容量有限会导致任意延迟 - 特定于操作系统/工作负载/系统负载。

4. 收集系统时间时产生的延迟 - 特定于语言/运行时。

5. 数据分块/缓冲:特定于套接字 [http 实现]。

练习:

Noe 有(1)的问题，而 Java/C# 的专用线程没有这个问题。但是由于node实现了事件驱动的非阻塞I/O模型，其他事件不会造成阻塞的影响，而是会被放入事件队列中。只有准备就绪的才会被触发，并且由于它们而引起的延迟将取决于它们必须执行多少 I/O 工作，以及在它们的关联回调中执行的任何 CPU 绑定(bind)操作。实际上，由于第 (2) 至 (5) 项的效果更为明显，这些在比较中将变得可以忽略不计并趋于平衡。此外，写入通常是非阻塞的，这意味着它们将在不等待下一个循环迭代运行的情况下执行。最后，当执行写入时，回调按顺序在线发出，中间不会屈服于另一个事件。

简而言之，如果将执行阻塞 I/O 的专用 Java 线程与 Node 代码进行比较，您会发现 Java 测量结果不错，但在大型应用程序中，线程上下文切换工作会抵消这种增益，而 Node 性能会脱颖而出。

希望这对您有所帮助。