对这些各种模式的上下文切换进行准确的定时是很困难的。我也可以认为这对你来说不太有用。相反，我会给出一些比较这些服务器环境的整个 HTTP 服务器性能的基本基准。请记住，影响整个端到端 HTTP 请求/响应路径的性能有很多因素，这里提供的数字只是我将一些样本放在一起进行基本比较的结果。
对于这些环境中的每一个，我写了适当的代码在一个 64k 文件中读取随机字节，在其上运行了一个 SHA-256 哈希 N 次（ N 在 URL 的查询字符串中指定，例如 .../test.php?n=100），并打印出结果十六进制散列。我选择这样做，是因为使用一些一致的 I/O 和受控的方式来运行相同的基准测试是一个增加 CPU 使用率的非常简单的方法。
有关使用的环境的更多细节，请参阅 基准说明 。
首先，我们来看一些低并发的例子。运行 2000 次迭代，300 个并发请求，每个请求只有一个散列（N = 1），结果如下：
时间是在所有并发请求中完成请求的平均毫秒数。越低越好。
仅从一张图很难得出结论，但是对我来说，似乎在大量的连接和计算量上，我们看到时间更多地与语言本身的一般执行有关，对于 I/O 更是如此。请注意，那些被视为“脚本语言”的语言（松散类型，动态解释）执行速度最慢。
但是，如果我们将 N 增加到 1000，仍然有 300 个并发请求，相同的任务，但是哈希迭代是 1000 倍（显着增加了 CPU 负载）：
时间是在所有并发请求中完成请求的平均毫秒数。越低越好。
突然间， Node 性能显著下降，因为每个请求中的 CPU 密集型操作都相互阻塞。有趣的是，在这个测试中，PHP 的性能要好得多（相对于其他的），并且打败了 Java。（值得注意的是，在 PHP 中，SHA-256 实现是用 C 编写的，在那个循环中执行路径花费了更多的时间，因为现在我们正在进行 1000 个哈希迭代）。
现在让我们尝试 5000 个并发连接（N = 1） - 或者是我可以发起的最大连接。不幸的是，对于大多数这些环境，故障率并不显着。对于这个图表，我们来看每秒的请求总数。 越高越好 :
每秒请求数。越高越好。
这个图看起来有很大的不同。我猜测，但是看起来像在高连接量时，产生新进程所涉及的每连接开销以及与 PHP + Apache 相关联的附加内存似乎成为主要因素，并阻止了 PHP 的性能。显然，Go 是这里的赢家，其次是 Java，Node，最后是 PHP。
虽然与你的整体吞吐量相关的因素很多，并且在应用程序之间也有很大的差异，但是你对底层发生什么的事情以及所涉及的权衡了解更多，你将会得到更好的结果。
总结以上所有这一切，很显然，随着语言的发展，处理大量 I/O 的大型应用程序的解决方案也随之发展。
为了公平起见，PHP 和 Java，尽管这篇文章中的描述，确实 实现了 在 web 应用程序 中 可使用的 非阻塞 I/O 。但是这些方法并不像上述方法那么常见，并且需要考虑使用这种方法来维护服务器的随之而来的操作开销。更不用说你的代码必须以与这些环境相适应的方式进行结构化；你的 “正常” PHP 或 Java Web 应用程序通常不会在这样的环境中进行重大修改。
作为比较，如果我们考虑影响性能和易用性的几个重要因素，我们得出以下结论：