[gist]为何事件驱动服务器这么火

from http://oyanglul.us

本文基本上这为两篇文章的翻译和整合 -- Scalable networking And Why are event-driven server so great

OPPC模型瓶颈

传统服务器模型如Apache为每个请求生成一个子进程。当用户链接到服务器的一个子进程就产生，并处理链接。每一个链接得到一个单独的线程和子进程。当用户请求数据返回时，子进程开始等待数据库操做返回。若是此时另外一个用户也请求返回数据，这时就产生了阻塞。

这种模式在很是小的工做负荷是表现良好，当请求的数量变得太大是服务器会压力过于巨大。 当Apache达到进程的最大数量，全部进程都变得缓慢。每一个请求都有本身的线程，若是服务代码使用PHP编写时，每一个进程所须要的内存量是至关大的[1]。

fork()操做延时

事实上，基于OPPC的网络并不如想象中的高效。首先新建进程的性能很大程度上依赖于操做系统对fork()的实现，然而不一样操做系统的处理并不是都理想。如图为各操做系统fork()的延迟时间对比。

操做系统fork操做只是简单的拷贝分页映射。动态连接为共享库和全局偏移表中的ELF（Executable and Linking Format）部分建立太多的分页映射。虽然静态的连接fork会是的性能大幅度提高，可是延时依然不乐观。

图 1 fork延时

进程调度

Linux每10毫秒（Alpha是1毫秒，该值为已编译常量）中断一次在运行态的进程，查看是否要切换别的进程执行。进程调度的任务就是决定下一个应该执行的进程，而其难度就在于如何公平的分配CPU资源。一个好的调度算法应该给每个进程都分享公平的CPU资源，并且不该该出现饥饿进程。

Unix系统采用多级反馈队列调度算法。使用多个不一样优先级的就绪队列，使用Heap保持队列按优先级顺序排序。Linux 2.6版本提供了一个复杂度O(1)的调度算法，将进程调度延时降至最小。可是进程调度的频率是100Hz，意味着10毫秒会停止一个进程而判断是否须要切换到另外一个进程。若是切换过多，会让CPU忙于切换，致使下降吞吐量。

内存占用与线程

　　建立多进程会带来另一个问题：内存消耗。

每个建立的进程都会占用内存，在Linux 2.6中的测试结果，400个左右的链接后fork()的性能要超过pthread_create()的性能。IBM对Linux作过优化后，一个进程能够处理10万个链接。fork（）在每个链接时都fork()一次成本过高，多线程在于须要考虑线程安全(thread-safe)与死锁(deadlock)，以及内存泄露问题这些问题。 　　

可靠性

该模型具备可靠性问题。一个配置不当的服务器，很容易遭受拒绝服务攻击（DoS）。当大量并发请求的服务器资源时，负载均衡配置不当时服务器会很快耗尽源而奔溃。

同步阻塞 I/O

在这个模型中，应用程序执行一个系统调用，这会致使应用程序阻塞。这意味着应用程序会一直阻塞，直到系统调用完成为止（数据传输完成或发生错误）。调用应用程序处于一种再也不占用CPU，而只是简单等待响应的状态，可是该进程依然占用着资源。当大量并发I/O请求到达时，则会产生I/O阻塞，形成服务器瓶颈。

事件驱动模型服务器

经过上诉分析与实验说明，事实上，操做系统并非设计来处理服务器工做负载。传统的线程模型是基于运行应用程序是的一些密集型操做的须要。 操做系统的设计是让用户执行的多线程程序，使后台文件写入和UI操做同时进行，而并非设计于处理大量并发请求链接。

Fork和多线程是至关费资源的操做，建立线程须要分配一个全新的内存堆栈。此外，上下文切换也是一项开销的，CPU调度模型是并不太适合一个传统的Web服务器。

所以，OPPC模型面临着多进程多线程的延迟已经内存消耗的问题。要用OPPC模型解决C10K问题显得十分复杂。

为解决C10K问题，一些新的服务器呈现出来。下列是解决C10K问题的Web服务器：

• nginx：一个基于事件驱动的处理请求架构反向代理服务器。
• Cherokee：Twitter使用的开源Web服务器。
• Tornado：一个Python语言实现的非阻塞式Web服务器框架。Facebook的FriendFeed模块使用此框架完成。
• Node.js：异步非阻塞Web服务器，运行于Google V8 JavaScript引擎。

显然以上解决C10K问题的服务器都有着共同特色：事件驱动，异步非阻塞技术。

因为网络负载工做包括大量的等待。好比 Apache服务器，产生大量的子进程，须要消耗大量内存。但大多数子进程占用大量内存资源却只是在等待一个阻塞任务结束。因为这一特色，新模型抛弃了对每一个请求生成子进程的想法。全部的请求和事物操做只使用一个单独的线程管理，此线程被称之为事件循环。事件循环将异步的管理全部用户链接与文件存储或数据库服务器。当请求到达时，使用poll或者select唤醒操做系统对其请求作相应处理。解决了不少问题。这样以来处理的并发请求再也不是牢牢围绕在阻塞资源。固然，这样也有必定的开销，如保持一个始终打开的TCP链接的列表，但内存并不会因为大量并发请求而急速上升，由于这个列表只占内存堆上很小的一部分。Node.js和Nginx的都用这种方法来构建应用程序的规模超级大的链接数。一切操做都由一个事件循环管理，并很好地处理多个链接[4]（图3）。

目前最为流行的事件驱动的异步非阻塞式I/O的Web服务器Node.js，称其会在内存占用上更为高效，并且因为不是传统OPPC模式，也不用担忧死锁。Node.js没有函数直接执行I/O操做[5]，所以也不会产生阻塞[6]。

图 3 事件驱动模型

图 4 传统OPPC模型

本文对目前应用最广的传统模型的Apache+PHP服务器，与两个流行事件驱动模型服务器Node.js，tornado，进行了压力测试。使用Apache bench对三个服务器分别进行每次1000个并发请求，总共100000次请求测试。分别监测和记录了三个服务器的内存与CPU占用状况。

实验环境为Ubuntu 11.10，Intel Celeron 1.86GHzCPU,内存1G(oh no,教研室的古董机子)。服务器分别为Apache2+PHP5.5,Node.js0.8.6和Tornado2.4.1。

{% include_code Nodejs nodeTest.sh %}

{% include_code Tornado tornadoTest.sh %}

{% include_code PHP phpTest.sh %}

图4 内存占用

图 5 CPU占用

在这个1000并发请求的压力测试中能够看到，基于事件驱动的Node.js与Tornado都比传统OPPC模型的Apache服务器要快。固然Node.js的性能也离不开其运行于Google V8引擎上的缘由。两个事件驱动模型服务器平均每秒处理的请求数为Apache服务器的一倍，而内存下降了一半。图2显示事件驱动模型服务器会占用更高的CPU，这说明这种模型虽然是单线程运行，可是能更高效的利用CPU处理更多的并发请求。

存在的不足

事件循环并不能解决一切问题[2]。特别是在Node.js的有一些缺陷。Node.js的最明显的遗漏是多线程的实现。事件驱动技术彷佛应该都是多线程进行的，如大多数事件驱动GUI框架。理论上来讲，事件之间应该是相互独立的关系，所以并行化应该并不难实现。

虽然理论上是这样，但一些技术上的缘由使得Node.js难以实现多线程。Node.js运行与Google的V8 Javascript引擎上[12]。V8引擎是一个高性能的JavaScript引擎，但它并无设计为多线程。由于它本来为Google Chrome浏览器Javascript引擎，浏览器中Javascropt在一个单线程上运行。所以添加多线程，将是很是艰难的，底层架构并不是为服务器而设计。

将来

随着nginx这样的反向代理服务器的发展，可让独立运行的实例之间的负载均衡，Node.js的做者提出对解决多线程缺陷的最好的办法是使用fork子进程，利用负载均衡来达到服务器并发任务处理。 这种解决方案彷佛像是要掩盖其实现上的缺陷。但事件驱动模型倡导一个逻辑服务器应该应该能在单核CPU下表现得最优，以及占用更少的内存。与此相反，Apache的最初目的是以一切可利用的资源为代价充分高效管理并发和线程。事件驱动模型服务器避开了这种繁琐的设计而用最简洁高效的方式实现了可扩展性良好的服务器。

单线程的也正符合云计算的平台的计算单位。很明显，一个单一的云实例，很是适合运行一个单一的Node.js的服务器，并使用负载均衡横向扩展。

事件驱动模型的出现，是为了解决传统服务器与网络工做负载的需求的不匹配，实现高度可伸缩服务器，并下降内存开销。事情驱动模型更改了链接到服务器的方式。全部的链接都由事件循环管理，每一个链接触发一个在事件循环进程中运行的事件，而不是为每一个链接生成一个新的 OS 线程，并为其分配一些配套内存。所以不用担忧出现死锁，并且不会直接调用阻塞资源，而采用异步的方式来实现非阻塞式I/O。经过事件驱动模型是的在相同配置的服务器能接受更多的并发请求，实现可伸缩的服务器。

[1] Suzumura, T.; Trent, S.; Tatsubori, M.; Tozawa, A.; Onodera, T.; , "Performance Comparison of Web Service Engines in PHP, Java and C," Web Services, 2008. ICWS '08. IEEE International Conference on , vol., no., pp.385-392, 23-26 Sept. 2008

[2] Von Behren, Rob, Jeremy Condit, and Eric Brewer. "Why events are a bad idea (for high-concurrency servers)." Proceedings of the 9th conference on Hot Topics in Operating Systems. Vol. 9. 2003.

[3]Welsh, Matt. "The staged event-driven architecture for highly-concurrent server applications." University of California, Berkeley (2000).

[4] Griffin, L., Ryan, K., de Leastar, E., Botvich, D., "Scaling Instant Messaging communication services: A comparison of blocking and non-blocking techniques", Computers and Communications (ISCC), 2011 IEEE Symposium on, On page(s): 550 - 557

[5] Tilkov, Stefan, and Steve Vinoski. "Node. js: Using JavaScript to build high-performance network programs." Internet Computing, IEEE 14.6 (2010): 80-83.

[6] Deitcher, Avi. "Simplicity and performance: JavaScript on the server." Linux Journal 2011.204 (2011): 3.

[11] W. Stevens. TCP/IP Illustrated Volume 3. Addison-Wesley, Reading, MA, 1996. [12]: http://code.google.com/apis/v8/design.html accessed

view raw 2012-12-31-node-dot-js-vs-tornado-vs-php.markdown hosted with ❤ by GitHub