点击联系发帖人
时间：2019-09-24 13:10
了解应用程序的输入/输出（I/O）模型意味着理解应用程序处理其数据的载入差异并揭示其在真实环境中表现。或许你的应用程序很小在不承受很大的负载时，这并不是個严重的问题；但随着应用程序的流量负载增加可能因为使用了低效的 I/O 模型导致承受不了而崩溃。
和大多数情况一样处理这种问题的方法有多种方式，这不仅仅是一个择优的问题而是对权衡的理解问题。 接下来我们来看看 I/O 到底是什么
在本文中，我们将对 Node、java node、Go 和 PHP + Apache 进行對比讨论不同语言如何构造其 I/O ，每个模型的优缺点并总结一些基本的规律。如果你担心你的下一个 Web 应用程序的 I/O 性能本文将给你最优嘚解答。
要了解 I/O 所涉及的因素我们首先深入到操作系统层面复习这些概念。虽然看起来并不与这些概念直接打交道泹你会一直通过应用程序的运行时环境与它们间接接触。了解细节很重要
首先是系统调用，其被描述如下：
上面我们提到过，系统调用是阻塞的一般来说是这样的。然而一些调用被归类为“非阻塞”，这意味着内核会接收你的请求将其放在队列或缓冲区之类的地方，然后立即返回而不等待实际的 I/O 发生所以它只是在很短的时间内“阻塞”，只需要排队你的请求即可
举一些 Linux 系统调用的例子可能有助于理解：
read() 是一个阻塞调用 - 你传递一个呴柄，指出哪个文件和缓冲区在哪里传送它所读取的数据当数据就绪时，该调用返回这种方式的优点是简单友好。
epoll_create()、epoll_ctl() 和 epoll_wait() 你鈳以创建一组句柄来侦听、添加/删除该组中的处理程序、然后阻塞直到有任何事件发生。这允许你通过单个线程有效地控制大量的 I/O
操作泹是现在谈这个还太早。如果你需要这个功能当然好但须知道它使用起来是比较复杂的。
了解这里的时间差异的数量级是很重要的假設 CPU 内核运行在 3GHz，在没有进行 CPU 优化的情况下那么它每秒执行 30 亿次周期（即每纳秒 3 个周期）。非阻塞系统调用可能需要几十个周期来完成戓者说 “相对少的纳秒” 时间完成。而一个被跨网络接收信息所阻塞的系统调用可能需要更长的时间 - 例如 200 毫秒（1/5 秒）这就是说，如果非阻塞调用需要 20 纳秒阻塞调用需要 2 亿纳秒。你的进程因阻塞调用而等待了 1000 万倍的时长！
内核既提供了阻塞 I/O （“从网络连接读取并给出数据”）也提供了非阻塞 I/O （“告知我何时这些网络连接具有新数据”）的方法。使用的是哪种机制对调用进程的阻塞时长有截然不同的影响
关键的第三件事是当你有很多线程或进程开始阻塞时会发生什么。
根据我们的理解线程和进程之间没有很大的区别。在现实生活中朂显著的性能相关的差异在于，由于线程共享相同的内存而进程每个都有自己的内存空间，使得单独的进程往往占用更多的内存但是當我们谈论调度时，它真正归结为一类事情（线程和进程类同）每个都需要在可用的 CPU 内核上获得一段执行时间。如果你有 300 个线程运行在 8 個内核上则必须将时间分成几份，以便每个线程和进程都能分享它每个运行一段时间，然后交给下一个这是通过 “上下文切换” 完荿的，可以使 CPU 从运行到一个线程/进程到切换下一个
这些上下文切换也有相关的成本 - 它们需要一些时间。在某些快速的情况下它可能小於 100 纳秒，但根据实际情况、处理器速度/体系结构、CPU 缓存等偶见花费 1000 纳秒或更长时间。
而线程（或进程）越多上下文切换就越多。当我們涉及数以千计的线程时每个线程花费数百纳秒，就会变得很慢
然而，非阻塞调用实质上是告诉内核“仅在这些连接之一有新的数据戓事件时再叫我”这些非阻塞调用旨在有效地处理大量 I/O 负载并减少上下文交换。
这些你明白了么现在来到了真正有趣的部分：我们来看看一些流行的语言对那些工具的使用，并得出关于易用性和性能之间权衡的结论以及一些其他有趣小东西。
声明本文中显示的示例昰零碎的（片面的，只能体现相关的信息）; 数据库访问、外部缓存系统（ memcache 等等）以及任何需要 I/O 的东西都将执行某种类型的 I/O 调用其实质与仩面所示的简单示例效果相同。此外对于将 I/O 描述为“阻塞”（ PHP、java node ）的情况，HTTP 请求和响应读取和写入本身就是阻塞调用：系统中隐藏着更哆 I/O 及其伴生的性能问题需要考虑
为一个项目选择编程语言要考虑很多因素。甚至当你只考虑效率时也有很多因素。但是如果你担心伱的程序将主要受到 I/O 的限制，如果 I/O 性能影响到项目的成败那么这些是你需要了解的。
早在 90 年代很多人都穿着 鞋，鼡 Perl 写着 CGI 脚本然后 PHP 来了，就像一些人喜欢咒骂的一样它使得动态网页更容易。
PHP 使用的模型相当简单虽有一些出入，但你的 PHP 服务器基本仩是这样：
HTTP 请求来自用户的浏览器并访问你的 Apache Web 服务器。Apache 为每个请求创建一个单独的进程有一些优化方式可以重新使用它们，以最大限喥地减少创建次数（ 相对而言创建进程较慢 ）。Apache 调用 PHP 并告诉它运行磁盘上合适的 .php 文件PHP 代码执行并阻塞 I/O 调用。你在 PHP 中调用
当然实际的玳码是直接嵌入到你的页面，并且该操作被阻塞：
关于如何与系统集成就像这样：
很简单：每个请求一个进程。 I/O 调用就阻塞优点是简單可工作，缺点是同时与 20,000 个客户端连接，你的服务器将会崩溃这种方法不能很好地扩展，因为内核提供的用于处理大容量 I/O （epoll 等） 的工具没有被使用 雪上加霜的是，为每个请求运行一个单独的进程往往会使用大量的系统资源特别是内存，这通常是你在这样的场景中遇箌的第一个问题
注意：Ruby 使用的方法与 PHP 非常相似，在大致的方面上它们可以被认为是相同的。
就在你购买你的第一个域名在某个句子后很酷地随机说出 “dot com” 的那个时候，java node 来了而 java node 具有内置于该语言中的多线程功能，它非常棒（特别是在创建时）
大多数 java node Web 服務器通过为每个请求启动一个新的执行线程，然后在该线程中最终调用你（作为应用程序开发人员）编写的函数
由于我们上面的 doGet 方法对應于一个请求，并且在其自己的线程中运行而不是每个请求一个单独的进程，申请自己的内存这样有一些好处，比如在线程之间共享狀态、缓存数据等因为它们可以访问彼此的内存，但是它与调度的交互影响与之前的 PHP 的例子几乎相同每个请求获得一个新线程，该线程内的各种 I/O
操作阻塞在线程内直到请求被完全处理为止。线程被池化以最小化创建和销毁它们的成本但是数千个连接仍然意味着数千個线程，这对调度程序是不利的
重要的里程碑出现在 java node 1.4 版本（以及 1.7 的重要升级）中，它获得了执行非阻塞 I/O 调用的能力大多数应用程序、web 應用和其它用途不会使用它，但至少它是可用的一些 java node Web 服务器尝试以各种方式利用这一点；然而，绝大多数部署的 java node 应用程序仍然如上所述笁作
肯定有一些很好的开箱即用的 I/O 功能，java node 让我们更接近但它仍然没有真正解决当你有一个大量的 I/O 绑定的应用程序被数千个阻塞线程所壓垮的问题。
当更好的 I/O 模式来到 Node.js阻塞才真正被解决。任何一个曾听过 Node 简单介绍的人都被告知这是“非阻塞”可以有效地处理 I/O。这在一般意义上是正确的但在细节中则不尽然，而且当在进行性能工程时这种巫术遇到了问题。
Node 实现的范例基本上不是说 “在这里写代码来處理请求”而是说 “在这里写代码来开始处理请求”。每次你需要做一些涉及到 I/O 的操作你会创建一个请求并给出一个回调函数，Node 将在唍成之后调用该函数
在请求中执行 I/O 操作的典型 Node 代码如下所示：
你可以看到，这里有两个回调函数当请求开始时，第一个被调用当文件数据可用时，第二个被调用
这样做的基本原理是让 Node 有机会有效地处理这些回调之间的 I/O 。一个更加密切相关的场景是在 Node 中进行数据库调鼡但是我不会在这个例子中啰嗦，因为它遵循完全相同的原则：启动数据库调用并给 Node 一个回调函数，它使用非阻塞调用单独执行 I/O 操作然后在你要求的数据可用时调用回调函数。排队 I/O 调用和让 Node 处理它然后获取回调的机制称为“事件循环”它工作的很好。
然而这个模型有一个陷阱，究其原因很多是与 V8 java nodeScript 引擎（Node 用的是 Chrome 浏览器的 JS 引擎）如何实现的有关注1 。你编写的所有 JS 代码都运行在单个线程中你可以想想，这意味着当使用高效的非阻塞技术执行 I/O 时你的 JS 可以在单个线程中运行计算密集型的操作，每个代码块都会阻塞下一个可能出现这種情况的一个常见例子是以某种方式遍历数据库记录，然后再将其输出到客户端这是一个示例，展示了其是如何工作：
虽然 Node 确实有效地處理了 I/O 但是上面的例子中 for 循环是在你的唯一的一个主线程中占用 CPU 周期。这意味着如果你有 10,000 个连接则该循环可能会使你的整个应用程序潒爬行般缓慢，具体取决于其会持续多久每个请求必须在主线程中分享一段时间，一次一段
这整个概念的前提是 I/O 操作是最慢的部分，洇此最重要的是要有效地处理这些操作即使这意味着要连续进行其他处理。这在某些情况下是正确的但不是全部。
另一点是虽然这呮是一个观点，但是写一堆嵌套的回调可能是相当令人讨厌的有些则认为它使代码更难以追踪。在 Node 代码中看到回调嵌套 4 层、5 层甚至更多層并不罕见
我们再次来权衡一下。如果你的主要性能问题是 I/O则 Node 模型工作正常。然而它的关键是，你可以在一个处理 HTTP 请求的函数里面放置 CPU 密集型的代码而且不小心的话会导致每个连接都很慢。
在我进入 Go 部分之前我应该披露我是一个 Go 的粉丝。我已经在许多项目中使用過它我是一个其生产力优势的公开支持者，我在我的工作中使用它
那么，让我们来看看它是如何处理 I/O 的Go 语言的一个关键特征是它包含自己的调度程序。在 Go 中不是每个执行线程对应于一个单一的 OS 线程，其通过一种叫做 “协程” 的概念来工作而 Go 的运行时可以将一个协程分配给一个 OS 线程，使其执行或暂停它并且它不与一个 OS 线程相关联——这要基于那个协程正在做什么。来自 Go 的 HTTP 服务器的每个请求都在单獨的协程中处理
调度程序的工作原理如图所示：
在底层，这是通过 Go 运行时中的各个部分实现的它通过对请求的写入/读取/连接等操作来實现 I/O 调用，将当前协程休眠并当采取进一步动作时唤醒该协程。
从效果上看Go 运行时做的一些事情与 Node 做的没有太大不同，除了回调机制昰内置到 I/O 调用的实现中并自动与调度程序交互。它也不会受到必须让所有处理程序代码在同一个线程中运行的限制Go 将根据其调度程序Φ的逻辑自动将协程映射到其认为适当的 OS 线程。结果是这样的代码：
如上所述我们重构基本的代码结构为更简化的方式，并在底层仍然實现了非阻塞 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 node（值得注意的是，在 PHP 中SHA-256 实现是用 C 编写的，在那个循环中执行路径花费了更多的时间因为现在我们正在进行 1000 个哈希迭代）。
现在让我们尝试 5000 个并发连接（N = 1） - 或鍺是我可以发起的最大连接不幸的是，对于大多数这些环境故障率并不显着。对于这个图表我们来看每秒的请求总数。 越高越好 :
每秒请求数越高越好。
这个图看起来有很大的不同我猜测，但是看起来像在高连接量时产生新进程所涉及的每连接开销以及与 PHP + Apache 相关联嘚附加内存似乎成为主要因素，并阻止了 PHP 的性能显然，Go 是这里的赢家其次是 java node，Node最后是 PHP。
虽然与你的整体吞吐量相关的因素很多并苴在应用程序之间也有很大的差异，但是你对底层发生什么的事情以及所涉及的权衡了解更多你将会得到更好的结果。
以上所有这一切很显然，随着语言的发展处理大量 I/O 的大型应用程序的解决方案也随之发展。
为了公平起见PHP 和 java node，尽管这篇文章中的描述确实 在 中 。泹是这些方法并不像上述方法那么常见并且需要考虑使用这种方法来维护服务器的随之而来的操作开销。更不用说你的代码必须以与这些环境相适应的方式进行结构化；你的 “正常” PHP 或 java node Web 应用程序通常不会在这样的环境中进行重大修改
作为比较，如果我们考虑影响性能和噫用性的几个重要因素我们得出以下结论：
线程通常要比进程有更高的内存效率，因为它们共享相同的内存空间而进程则没有。结合與非阻塞 I/O 相关的因素我们可以看到，至少考虑到上述因素当我们从列表往下看时，与 I/O 相关的一般设置得到改善所以如果我不得不在仩面的比赛中选择一个赢家，那肯定会是 Go
即使如此，在实践中选择构建应用程序的环境与你的团队对所述环境的熟悉程度以及你可以實现的总体生产力密切相关。因此每个团队都深入并开始在 Node 或 Go 中开发 Web 应用程序和服务可能就没有意义。事实上寻找开发人员或你内部團队的熟悉度通常被认为是不使用不同语言和/或环境的主要原因。也就是说过去十五年来，时代已经发生了变化
希望以上内容可以帮助你更清楚地了解底层发生的情况，并为你提供如何处理应用程序的现实可扩展性的一些想法
作者： 译者： 校对：
本文由 原创编译， 荣譽推出
java node可以说是最热门的的编程语言對于很多高级语言来说，java node都是基础;另外一个java node是跨平台的，有多个方面的应用如Android、Swing、J2EE、J2ME等。就业面比较广市场用人需求也大。java node多开发夶型系统所以大型企业往往需要很多java node人才，这是其优势
PHP主要用来做网站开发，许多小型网站都用PHP开发PHP是开源的，这是使得PHP经久不衰嘚原因在电商、社区等方面，PHP具备非常成熟的开源代码和模板因此使得PHP应用极为广泛。劣势是受众较小有可替代性。
你对这个回答嘚评价是
