Node、PHP、Java 和 Go 服务端 I/O 性能PK

理解应用程序的输入/输出（I/O）模型，意味着其在计划处理负载与残酷的实际使用剑钕饿粪场景之间的差异。若应用程序比较小，也没有貅冥尜坼服务于很高的负载，也许它影响甚微。但随着应用程序的负载逐渐上涨，采用错误的I/O模型有可能会让你到处踩坑，伤痕累累。正如大部分存在多种解决途径的场景一样，重点不在于哪一种途径更好，而是在于理解如何进行权衡。让我们借《Linux就该这么学》-技术干货-《Node、PHP、Java 和 Go 服务端 I/O 性能PK》来参观下I/O的景观，看下可以从中窃取点什么。在这篇文章，我们将会结合Apache分别比较Node，Java，Go，和PHP，讨论这些不同的语言如何对他们的I/O进行建模，各个模型的优点和缺点，并得出一些初步基准的结论。如果关心你下一个Web应用的I/O性能，那你就找对文章了。

3、阻塞调用与非阻塞调用好了，我刚刚在上面说系统调用是阻塞的，通常来说这是对的。然而，有些调用被分类为“非阻塞”，意味着内核接钝鸵捎貌收了你的请求后，把它放进了队列或者缓冲的某个地方，然后立即返回而并没有等待实际的I/O调用。所以它只是“阻塞”了一段非常短的时间，短到只是把你的请求入列而已。这里有一些有助于解释清楚的（Linux系统调用）例子：-read()是阻塞调用——你传给它一个文件句柄和一个存放所读到数据的缓冲，然后此调用会在当数据好后返回。注意这种方式有着优雅和简单的优点。-epoll_create()，epoll_ctl()，和epoll_wait()这些调用分别是，让你创建一组用于侦听的句柄，从该组添加/删除句柄，和然后直到有活动时才阻塞。这使得你可以通过一个线程有效地控制一系列I/O操作。如果需要这些功能，这非常棒，但也正如你所看到的，使用起来当然也相当复杂。理解这里分时差异的数量级是很重要的。如果一个CPU内核运行在3GHz，在没有优化的情况下，它每秒执行30亿次循环（或者每纳秒3次循环）。非阻塞系统调用可能需要10纳秒这样数量级的周期才能完成——或者“相对较少的纳秒”。对于正在通过网络接收信息的阻塞调用可能需要更多的时间——例如200毫秒（0.2秒）。例如，假设非阻塞调用消耗了20纳秒，那么阻塞调用消耗了200,000,000纳秒。对于阻塞调用，你的程序多等待了1000万倍的时间。

10、相当简单：一个请求，一个进程。I/O是阻塞的。优点是什么呢？简单，可行。那缺点是什么呢？同时与20,000个客户端连接，你的服务器就挂了。由于内核提供的用于处理大容量I/O（epoll等）的工具没有被使用，所以这种方法不能很好地扩展。更糟糕的是，为每个请求运行一个单独的过程往往会使用大量的系统资源，尤其是内存，这通常是在这样的场景中遇到的第一件事情。注意：Ruby使用的方法与PHP非常相似，在广泛而普遍的方式下，我们可以将其视为是相同的。

多线程的方式：Java

1、所以就在你买了你的第一个域名的时候，Java来了，并且在一个句子之后随便说一句“dot com”是很酷的。而Java具有语言内置的多线程（特别是在创建时），这一点非常棒。大多数Java网站服务器通过为每个进来的请求启动一个新的执行线程，然后在该线程中最终调用作为应用程序开发人员的你所编写的函数。

2、在Java的Servlet中执行I/O操作，往往看起来像是这样：public vo坡纠课柩id doGet(HttpServ造婷用痃letRequest request, HttpServletResponse response) throws ServletException, IOException{ // 阻塞的文件I/O InputStream fileIs = new FileInputStream("/path/to/file"); // 阻塞的网络I/O URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection(); InputStream netIs = urlConnection.getInputStream(); // 更多阻塞的网络I/O out.println("...");}

3、由于我们上面的doGet方法对应于一个请求并且在自己的线程中运行，而不是每次请求都对应需要有自己专属内存的单独进程，所以我们会有一个单独的线程。这样会有一些不错的优点，例如可以在线程之间共享状态、共享缓存的数据等，因为它们可以相互访问各自的内存，但是它如何与调度进行交互的影响，仍然与前面PHP例子中所做的内容几乎一模一样。每个请求都会产生一个新的线程，而在这个线程中的各种I/O操作会一直阻塞，直到这个请求被完全处理为止。为了最小化创建和销毁它们的成本，线程会被汇集在一起，但是依然，有成千上万个连接就意味着成千上万个线程，这对于调度器是不利的。一个重要的里程碑是，在Java 1.4 版本（和再次显著升级的1.7 版本）中，获得了执行非阻塞I/O调用的能力。大多数应用程序，网站和其他程序，并没有使用它，但至少它是可获得的。一些Java网站服务器尝试以各种方式利用这一点; 然而，绝大多数已经部署的Java应用程序仍然如上所述那样工作。

4、然而，这个模型中有一道关卡。在幕后，究其原因，更多是如何实现JavaScript V8 引擎（Chrome的JS引擎，用于Node）1，而不是其他任何事情。你所编写的JS代码全部都运行在一个线程中。思考一下。这意味着当使用有效的非阻塞技术执行I/O时，正在进行CPU绑定操作的JS可以在运行在单线程中，每个代码块阻塞下一个。 一个常见的例子是循环数据库记录，在输出到客户端前以某种方式处理它们。以下是一个例子，演示了它如何工作：

5、var handler = function(request, response) { connection.query('SELECT ...', function (err, rows) { if (err) { throw err }; for (var i = 0; i < rows.length; i++) { // 对每一行纪录进行处理 } response.end(...); // 输出结果 })};

6、虽然Node确实可以有效地处理I/O，但上面的例子中的for循环使用的是在你主线程中的CPU周期。这意味着，如果你有10,000个连接，该循环有可能会让你整个应用程序慢如蜗牛，具体取决于每次循环需要多长时间。每个请求必须分享在主线程中的一段时间，一次一个。这个整体概念的前提是I/O操作是最慢的部分，因此最重要是有效地处理这些操作，即使意味着串行进行其他处理。这在某些情况下是正确的，但不是全都正确。

7、另一点是，虽然这只是一个意见，但是写一堆嵌套的回调可能会令人相当讨厌，有些人认为它使得代码明显无章可循。在Node代码的深处，看到嵌套四层、嵌套五层、甚至更多层级的嵌套并不罕见。我们再次回到了权衡。如果你主要的性能问题在于I/O，那么Node模型能很好地工作。然而，它的阿喀琉斯之踵（译者注：来自希腊神话，表示致命的弱点）是如果不小心的话，你可能会在某个函数里处理HTTP请求并放置CPU密集型代码，最后使得每个连接慢得如蜗牛。

真正的非阻塞：Go

1、在进入Go这一章节之前，我应该披露我是一名Go粉丝。我已经在许多项目中使用Go，是其生产力优势的公开支持者，并且在使用时我在工作中看到了他们。也就是说，我们来看看它是如何处理I/O的。Go语言的一个关键特性是它包含自己的调度器。并不是每个线程的执行对应于一个单一的OS线程，Go采用的是“goroutines”这一概念。Go运行时可以将一个goroutine分配给一个OS线程并使其执行，或者把它挂起而不与OS线程关联，这取决于goroutine做的是什么。来自Go的HTTP服务器的每个请求都在单独的Goroutine中处理。

2、此调度器工作的示意图，如下所示：

3、时间是在全部并发请求中完成请求的平均毫秒数。越低越好。

4、很难从一个图表就得出结论，但对于我来说，似乎与连接和计算量这些方面有关，我们看到时间更多地与语言本身的一般执行有关，因此更多在于I/O。请注意，被认为是“脚本语言”（输入随意，动态解释）的语言执行速度最慢。但是如果将N增加到1000，仍然并发300个请求，会发生什么呢 —— 相同的负载，但是hash迭代是之前的100倍（显着增加了CPU负载）：

6、每秒的请求总数。越高越好。

7、这张照片看起来截然不同。这是一个猜测，但是看起来像是对于高连接量，每次连接的开销与产生新进程有关，而与PHP + Apache相关联的额外内存似乎成为主要的因素并制约了PHP的性能。显然，Go是这里的冠军，其次是Java和Node，最后是PHP。

结论

1、综上所述，很显然，随着语言的演进，处理大量I/O的大型应用程序的解决方案也随之不断演进。为了公平起见，暂且抛开本文的描述，PHP和Java确实有可用于Web应用程序的非阻塞I/O的实现。 但是这些方法并不像上述方法那么常见，并且需要考虑使用这种方法来维护服务器的伴随的操作开销。更不用说你的代码必须以与这些环境相适应的方式进行结构化; “正常”的PHP或Java Web应用程序通常不会在这样的环境中进行重大改动。

2、作为比较，如果只考虑影响性能和易用性的几个重要因素，可以得到：语言 线程或进程 非阻塞I/O 易用性PHP 进程 否 Java 线程 可用 需要回调Node.js 线程 是 需要回调Go 线程（Goroutine） 是 不需要回调

3、线程通常要比进程有更高的内存效率，因为它们共享相同的内存空间，而进程则没有。结合与非阻塞I/O相蔡龇呶挞关的因素，当我们向下移动列表到一般的启动时，因为它与改善I/O有关，可以看到至少与上面考虑的因素一样。如果我不得不在上面的比赛中选出一个冠军，那肯定会是Go。即便这样，在实践中，选择构建应用程序的环境与你的团队对于所述环境的熟悉程度以及可以实现的总体生产力密切相关。因此，每个团队只是一味地扎进去并开始用Node或Go开发Web应用程序和服务可能没有意义。事实上，寻找开发人员或内部团队的熟悉度通常被认为是不使用不同的语言和/或不同的环境的主要原因。也就是说，过去的十五年来，时代已经发生了巨大的变化。希望以上内容可以帮助你更清楚地了解幕后所发生的事件，并就如何处理应用程序现实世界中的可扩展性为你提供的一些想法。快乐输入，快乐输出！