了解应用程序的输入/输出（I/O）模型意味着理解应用程序处理其数据的载入差异，并揭示其在真实环境中表现。或许你的应用程序很小，在不承受很大的负载时，这并不是个严重的问题；但随着应用程序的流量负载增加，可能因为使用了低效的 I/O 模型导致承受不了而崩溃。
和大多数情况一样，处理这种问题的方法有多种方式，这不仅仅是一个择优的问题，而是对权衡的理解问题。 接下来我们来看看 I/O 到底是什么。
在本文中，我们将对 Node、Java、Go 和 PHP + Apache 进行对比，讨论不同语言如何构造其 I/O ，每个模型的优缺点，并总结一些基本的规律。如果你担心你的下一个 Web 应用程序的 I/O 性能，本文将给你最优的解答。
I/O 基础知识: 快速复习
要了解 I/O 所涉及的因素，我们首先深入到操作系统层面复习这些概念。虽然看起来并不与这些概念直接打交道，但你会一直通过应用程序的运行时环境与它们间接接触。了解细节很重要。
系统调用
首先是系统调用，其被描述如下：
- 程序（所谓“ 用户端 user land ”）必须请求操作系统内核代表它执行 I/O 操作。
- “ 系统调用 syscall ”是你的程序要求内核执行某些操作的方法。这些实现的细节在操作系统之间有所不同，但基本概念是相同的。有一些具体的指令会将控制权从你的程序转移到内核（类似函数调用，但是使用专门用于处理这种情况的专用方式）。一般来说，系统调用会被阻塞，这意味着你的程序会等待内核返回（控制权到）你的代码。
- 内核在所需的物理设备（ 磁盘、网卡等 ）上执行底层 I/O 操作，并回应系统调用。在实际情况中，内核可能需要做许多事情来满足你的要求，包括等待设备准备就绪、更新其内部状态等，但作为应用程序开发人员，你不需要关心这些。这是内核的工作。
阻塞与非阻塞
上面我们提到过，系统调用是阻塞的，一般来说是这样的。然而，一些调用被归类为“非阻塞”，这意味着内核会接收你的请求，将其放在队列或缓冲区之类的地方，然后立即返回而不等待实际的 I/O 发生。所以它只是在很短的时间内“阻塞”，只需要排队你的请求即可。
举一些 Linux 系统调用的例子可能有助于理解：
read()是一个阻塞调用 - 你传递一个句柄，指出哪个文件和缓冲区在哪里传送它所读取的数据，当数据就绪时，该调用返回。这种方式的优点是简单友好。- 分别调用
epoll_create()、epoll_ctl()和epoll_wait()，你可以创建一组句柄来侦听、添加/删除该组中的处理程序、然后阻塞直到有任何事件发生。这允许你通过单个线程有效地控制大量的 I/O 操作，但是现在谈这个还太早。如果你需要这个功能当然好，但须知道它使用起来是比较复杂的。
了解这里的时间差异的数量级是很重要的。假设 CPU 内核运行在 3GHz，在没有进行 CPU 优化的情况下，那么它每秒执行 30 亿次 周期 cycle （即每纳秒 3 个周期）。非阻塞系统调用可能需要几十个周期来完成，或者说 “相对少的纳秒” 时间完成。而一个被跨网络接收信息所阻塞的系统调用可能需要更长的时间 - 例如 200 毫秒（1/5 秒）。这就是说，如果非阻塞调用需要 20 纳秒，阻塞调用需要 2 亿纳秒。你的进程因阻塞调用而等待了 1000 万倍的时长！
内核既提供了阻塞 I/O （“从网络连接读取并给出数据”），也提供了非阻塞 I/O （“告知我何时这些网络连接具有新数据”）的方法。使用的是哪种机制对调用进程的阻塞时长有截然不同的影响。
调度
关键的第三件事是当你有很多线程或进程开始阻塞时会发生什么。
根据我们的理解，线程和进程之间没有很大的区别。在现实生活中，最显著的性能相关的差异在于，由于线程共享相同的内存，而进程每个都有自己的内存空间，使得单独的进程往往占用更多的内存。但是当我们谈论 调度 Scheduling 时，它真正归结为一类事情（线程和进程类同），每个都需要在可用的 CPU 内核上获得一段执行时间。如果你有 300 个线程运行在 8 个内核上，则必须将时间分成几份，以便每个线程和进程都能分享它，每个运行一段时间，然后交给下一个。这是通过 “ 上下文切换 context switch ” 完成的，可以使 CPU 从运行到一个线程/进程到切换下一个。
这些上下文切换也有相关的成本 - 它们需要一些时间。在某些快速的情况下，它可能小于 100 纳秒，但根据实际情况、处理器速度/体系结构、CPU 缓存等，偶见花费 1000 纳秒或更长时间。
而线程（或进程）越多，上下文切换就越多。当我们涉及数以千计的线程时，每个线程花费数百纳秒，就会变得很慢。
然而，非阻塞调用实质上是告诉内核“仅在这些连接之一有新的数据或事件时再叫我”。这些非阻塞调用旨在有效地处理大量 I/O 负载并减少上下文交换。
这些你明白了么？现在来到了真正有趣的部分：我们来看看一些流行的语言对那些工具的使用，并得出关于易用性和性能之间权衡的结论，以及一些其他有趣小东西。
声明，本文中显示的示例是零碎的（片面的，只能体现相关的信息）; 数据库访问、外部缓存系统（ memcache 等等）以及任何需要 I/O 的东西都将执行某种类型的 I/O 调用，其实质与上面所示的简单示例效果相同。此外，对于将 I/O 描述为“阻塞”（ PHP、Java ）的情况，HTTP 请求和响应读取和写入本身就是阻塞调用：系统中隐藏着更多 I/O 及其伴生的性能问题需要考虑。
为一个项目选择编程语言要考虑很多因素。甚至当你只考虑效率时，也有很多因素。但是，如果你担心你的程序将主要受到 I/O 的限制，如果 I/O 性能影响到项目的成败，那么这些是你需要了解的。
“保持简单”方法：PHP
早在 90 年代，很多人都穿着 Converse 鞋，用 Perl 写着 CGI 脚本。然后 PHP 来了，就像一些人喜欢咒骂的一样，它使得动态网页更容易。
PHP 使用的模型相当简单。虽有一些出入，但你的 PHP 服务器基本上是这样：
HTTP 请求来自用户的浏览器，并访问你的 Apache Web 服务器。Apache 为每个请求创建一个单独的进程，有一些优化方式可以重新使用它们，以最大限度地减少创建次数（ 相对而言，创建进程较慢 ）。Apache 调用 PHP 并告诉它运行磁盘上合适的 .php 文件。PHP 代码执行并阻塞 I/O 调用。你在 PHP 中调用 file_get_contents() ，其底层会调用 read() 系统调用并等待结果。
当然，实际的代码是直接嵌入到你的页面，并且该操作被阻塞：
关于如何与系统集成，就像这样：
很简单：每个请求一个进程。 I/O 调用就阻塞。优点是简单可工作，缺点是，同时与 20,000 个客户端连接，你的服务器将会崩溃。这种方法不能很好地扩展，因为内核提供的用于处理大容量 I/O （epoll 等） 的工具没有被使用。 雪上加霜的是，为每个请求运行一个单独的进程往往会使用大量的系统资源，特别是内存，这通常是你在这样的场景中遇到的第一个问题。
注意：Ruby 使用的方法与 PHP 非常相似，在大致的方面上，它们可以被认为是相同的。
多线程方法： Java
就在你购买你的第一个域名，在某个句子后很酷地随机说出 “dot com” 的那个时候，Java 来了。而 Java 具有内置于该语言中的多线程功能，它非常棒（特别是在创建时）。
大多数 Java Web 服务器通过为每个请求启动一个新的执行线程，然后在该线程中最终调用你（作为应用程序开发人员）编写的函数。
在 Java Servlet 中执行 I/O 往往看起来像：
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
// blocking file I/O
InputStream fileIs = new FileInputStream("/path/to/file");
// blocking network I/O
URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
InputStream netIs = urlConnection.getInputStream();
// some more blocking network I/O
out.println("...");
}
由于我们上面的 doGet 方法对应于一个请求，并且在其自己的线程中运行，而不是每个请求一个单独的进程，申请自己的内存。这样有一些好处，比如在线程之间共享状态、缓存数据等，因为它们可以访问彼此的内存，但是它与调度的交互影响与之前的 PHP 的例子几乎相同。每个请求获得一个新线程，该线程内的各种 I/O 操作阻塞在线程内，直到请求被完全处理为止。线程被池化以最小化创建和销毁它们的成本，但是数千个连接仍然意味着数千个线程，这对调度程序是不利的。
重要的里程碑出现在 Java 1.4 版本（以及 1.7 的重要升级）中，它获得了执行非阻塞 I/O 调用的能力。大多数应用程序、web 应用和其它用途不会使用它，但至少它是可用的。一些 Java Web 服务器尝试以各种方式利用这一点；然而，绝大多数部署的 Java 应用程序仍然如上所述工作。
肯定有一些很好的开箱即用的 I/O 功能，Java 让我们更接近，但它仍然没有真正解决当你有一个大量的 I/O 绑定的应用程序被数千个阻塞线程所压垮的问题。
无阻塞 I/O 作为一等公民： Node
当更好的 I/O 模式来到 Node.js，阻塞才真正被解决。任何一个曾听过 Node 简单介绍的人都被告知这是“非阻塞”，可以有效地处理 I/O。这在一般意义上是正确的。但在细节中则不尽然，而且当在进行性能工程时，这种巫术遇到了问题。
Node 实现的范例基本上不是说 “在这里写代码来处理请求”，而是说 “在这里写代码来开始处理请求”。每次你需要做一些涉及到 I/O 的操作，你会创建一个请求并给出一个回调函数，Node 将在完成之后调用该函数。
在请求中执行 I/O 操作的典型 Node 代码如下所示：
http.createServer(function(request, response) {
fs.readFile('/path/to/file', 'utf8', function(err, data) {
response.end(data);
});
});
你可以看到，这里有两个回调函数。当请求开始时，第一个被调用，当文件数据可用时，第二个被调用。
这样做的基本原理是让 Node 有机会有效地处理这些回调之间的 I/O 。一个更加密切相关的场景是在 Node 中进行数据库调用，但是我不会在这个例子中啰嗦，因为它遵循完全相同的原则：启动数据库调用，并给 Node 一个回调函数，它使用非阻塞调用单独执行 I/O 操作，然后在你要求的数据可用时调用回调函数。排队 I/O 调用和让 Node 处理它然后获取回调的机制称为“事件循环”。它工作的很好。
然而，这个模型有一个陷阱，究其原因，很多是与 V8 JavaScript 引擎（Node 用的是 Chrome 浏览器的 JS 引擎）如何实现的有关 注1 。你编写的所有 JS 代码都运行在单个线程中。你可以想想，这意味着当使用高效的非阻塞技术执行 I/O 时，你的 JS 可以在单个线程中运行计算密集型的操作，每个代码块都会阻塞下一个。可能出现这种情况的一个常见例子是以某种方式遍历数据库记录，然后再将其输出到客户端。这是一个示例，展示了其是如何工作：
var handler = function(request, response) {
connection.query('SELECT ...', function (err, rows) {
if (err) { throw err };
for (var i = 0; i < rows.length; i++) {
// do processing on each row
}
response.end(...); // write out the results
})
};
虽然 Node 确实有效地处理了 I/O ，但是上面的例子中 for 循环是在你的唯一的一个主线程中占用 CPU 周期。这意味着如果你有 10,000 个连接，则该循环可能会使你的整个应用程序像爬行般缓慢，具体取决于其会持续多久。每个请求必须在主线程中分享一段时间，一次一段。
这整个概念的前提是 I/O 操作是最慢的部分，因此最重要的是要有效地处理这些操作，即使这意味着要连续进行其他处理。这在某些情况下是正确的，但不是全部。
另一点是，虽然这只是一个观点，但是写一堆嵌套的回调可能是相当令人讨厌的，有些则认为它使代码更难以追踪。在 Node 代码中看到回调嵌套 4 层、5 层甚至更多层并不罕见。
我们再次来权衡一下。如果你的主要性能问题是 I/O，则 Node 模型工作正常。然而，它的关键是，你可以在一个处理 HTTP 请求的函数里面放置 CPU 密集型的代码，而且不小心的话会导致每个连接都很慢。
最自然的非阻塞：Go
在我进入 Go 部分之前，我应该披露我是一个 Go 的粉丝。我已经在许多项目中使用过它，我是一个其生产力优势的公开支持者，我在我的工作中使用它。
那么，让我们来看看它是如何处理 I/O 的。Go 语言的一个关键特征是它包含自己的调度程序。在 Go 中，不是每个执行线程对应于一个单一的 OS 线程，其通过一种叫做 “ 协程 goroutine ” 的概念来工作。而 Go 的运行时可以将一个协程分配给一个 OS 线程，使其执行或暂停它，并且它不与一个 OS 线程相关联——这要基于那个协程正在做什么。来自 Go 的 HTTP 服务器的每个请求都在单独的协程中处理。
调度程序的工作原理如图所示：
在底层，这是通过 Go 运行时中的各个部分实现的，它通过对请求的写入/读取/连接等操作来实现 I/O 调用，将当前协程休眠，并当采取进一步动作时唤醒该协程。
从效果上看，Go 运行时做的一些事情与 Node 做的没有太大不同，除了回调机制是内置到 I/O 调用的实现中，并自动与调度程序交互。它也不会受到必须让所有处理程序代码在同一个线程中运行的限制，Go 将根据其调度程序中的逻辑自动将协程映射到其认为适当的 OS 线程。结果是这样的代码：
func ServeHTTP(w http.ResponseWriter, r *http.Request) {
// the underlying network call here is non-blocking
rows, err := db.Query("SELECT ...")
for _, row := range rows {
// do something with the rows,
// each request in its own goroutine
}
w.Write(...) // write the response, also non-blocking
}
如上所述，我们重构基本的代码结构为更简化的方式，并在底层仍然实现了非阻塞 I/O。
在大多数情况下，最终是“两全其美”的。非阻塞 I/O 用于所有重要的事情，但是你的代码看起来像是阻塞，因此更容易理解和维护。Go 调度程序和 OS 调度程序之间的交互处理其余部分。这不是完整的魔法，如果你建立一个大型系统，那么值得我们来看看有关它的工作原理的更多细节；但与此同时，你获得的“开箱即用”的环境可以很好地工作和扩展。
Go 可能有其缺点，但一般来说，它处理 I/O 的方式不在其中。
谎言，可恶的谎言和基准
对这些各种模式的上下文切换进行准确的定时是很困难的。我也可以认为这对你来说不太有用。相反，我会给出一些比较这些服务器环境的整个 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 应用程序通常不会在这样的环境中进行重大修改。
作为比较，如果我们考虑影响性能和易用性的几个重要因素，我们得出以下结论：
| 语言 | 线程与进程 | 非阻塞 I/O | 使用便捷性 |
|---|---|---|---|
| PHP | 进程 | 否 | |
| Java | 线程 | 可用 | 需要回调 |
| Node.js | 线程 | 是 | 需要回调 |
| Go | 线程 （协程） | 是 | 不需要回调 |
线程通常要比进程有更高的内存效率，因为它们共享相同的内存空间，而进程则没有。结合与非阻塞 I/O 相关的因素，我们可以看到，至少考虑到上述因素，当我们从列表往下看时，与 I/O 相关的一般设置得到改善。所以如果我不得不在上面的比赛中选择一个赢家，那肯定会是 Go。
即使如此，在实践中，选择构建应用程序的环境与你的团队对所述环境的熟悉程度以及你可以实现的总体生产力密切相关。因此，每个团队都深入并开始在 Node 或 Go 中开发 Web 应用程序和服务可能就没有意义。事实上，寻找开发人员或你内部团队的熟悉度通常被认为是不使用不同语言和/或环境的主要原因。也就是说，过去十五年来，时代已经发生了变化。
希望以上内容可以帮助你更清楚地了解底层发生的情况，并为你提供如何处理应用程序的现实可扩展性的一些想法。
via: https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
作者：BRAD PEABODY 译者：MonkeyDEcho 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
