使用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发送一起触发，并在发送获得机会之前按顺序执行 - 节点特定。

2. 线程/进程切换，可以在发送操作范围内的任何时间发生 - 通用。

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

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

5. 数据的分块/缓冲：socket [http implementation] specific。

实践：

Noe遇到（1），而Java / C＃的专用线程没有这个问题。但是，当节点实现事件驱动的非阻塞I / O模型时，其他事件不会导致阻塞效应，而是将其置于事件队列中。只有准备好的那些将被解雇，由它们引起的延迟将取决于它们必须执行多少I / O工作，以及在其关联的回调中执行的任何CPU绑定操作。在实践中，由于项目（2）至（5）的更明显的影响，这些在比较中将变得可以忽略不计并且平均化。此外，写入通常是非阻塞的，这意味着它们将在不等待下一个循环迭代运行的情况下执行。最后，当执行写操作时，回调是按行和顺序发出的，其间没有屈服于另一个事件。

简而言之，如果将执行阻塞I / O的专用Java线程与节点代码进行比较，您将看到Java测量很好，但在大规模应用程序中，线程上下文切换工作将抵消此增益和节点性能会脱颖而出。

希望这有帮助。