使用node.js测量http请求时间
我使用node.js发送一个http请求。 我有一个要求来衡量花了多less时间。
start = getTime() http.send(function(data) {end=getTime()}) 如果我在http响应callback中调用getTime，那么当响应由于队列中的其他事件而回来时，有可能没有立即调用我的callback。 如果我为这个任务使用常规的java或者c＃同步代码，这样的风险也存在，因为另一个线程可能在我之前受到了关注。
start = getTime() http.send() end=getTime()
node.js如何与其他（同步）平台进行比较 – 是否让我有机会获得更好或更差的好处？
伟大的观察！
理论：
如果您正在执行微基准testing，则存在一些可能会使测量偏差的考虑事项：
-
事件循环中的其他事件，这些事件随着发送的http发送而准备发送，并且在发送之前得到一个机会 – 特定的节点。
-
线程/进程切换可以在发送操作的范围内随时发生 – 通用。
-
内核的I / O缓冲区处于有限的容量导致任意延迟 – 操作系统/工作负载/系统负载特定。
-
收集系统时间的时间延迟 – 语言/运行时特定的。
-
分块/缓冲数据：socket [http实现]具体。
实践：
Noe患有（1），而Java / C＃的专用线程没有这个问题。 但是当节点实现一个事件驱动的非阻塞I / O模型时，其他事件不会造成阻塞效应，反而会被放入事件队列。 只有那些准备好的才会被解雇，由此产生的延迟将是他们必须执行多lessI / O工作以及在相关callback中执行的任何CPU绑定操作的函数。 由于（2）至（5）项的更明显的效果，这些在实践中会变得可以忽略不计，并在比较中变得平均。 另外，写入通常是非阻塞的，这意味着它们将在不等待下一个循环迭代运行的情况下执行。 最后，在执行写入操作时，callback将按顺序并顺序发出，不会产生中间的其他事件。
简而言之，如果比较专用的Java线程阻塞I / O和Node代码，您将看到Java测量结果不错，但在大规模应用程序中，线程上下文切换的努力将抵消这种收益，并且节点性能将突出。
希望这可以帮助。