OPPC模型瓶颈
传统服务器模型如Apache为每一个请求生成一个子进程。当用户连接到服务器的一个子进程就产生，并处理连接。每个连接获得一个单独的线程和子进程。当用户请求数据返回时，子进程开始等待数据库操作返回。如果此时另一个用户也请求返回数据，这时就产生了阻塞。
这种模式在非常小的工作负荷是表现良好，当请求的数量变得太大是服务器会压力过于巨大。 当Apache达到进程的最大数量，所有进程都变得缓慢。每个请求都有自己的线程，如果服务代码使用PHP编写时，每个进程所需要的内存量是相当大的。
fork()操作延时
fork()函数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都用这种方法来构建连接数超大的应用程序。一切操作都由一个事件循环管理，并很好地处理多个连接。
目前最为流行的事件驱动的异步非阻塞式I/O的Web服务器Node.js，称其会在内存占用上更为高效，而且由于不是传统OPPC模式，也不用担心死锁。Node.js没有函数直接执行I/O操作，因此也不会产生阻塞。
图 2 事件驱动模型
图 3 传统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处理更多的并发请求。
存在的不足
事件循环并不能解决一切问题。特别是在Node.js上有一些缺陷。Node.js最明显的遗漏是多线程的实现。事件驱动技术似乎应该都是多线程进行的，如大多数事件驱动GUI框架。理论上来说，事件之间应该是相互独立的关系，因此应该并不难实现并行化。
虽然理论上是这样，但一些技术上的原因使得Node.js难以实现多线程。Node.js运行在Google的V8 Javascript引擎上。V8引擎是一个高性能的JavaScript引擎，但它并没有设计为多线程。因为它原本为Google Chrome浏览器Javascript引擎，浏览器中Javascript在一个单线程上运行。因此添加多线程，将是非常艰难的，底层架构并非为服务器而设计。
未来
随着nginx这样的反向代理服务器的发展，可以让独立运行的实例之间的负载均衡，Node.js的作者提出对解决多线程缺陷的最好的办法是使用fork子进程，利用负载均衡来达到服务器并发任务处理。 这种解决方案似乎像是要掩盖其实现上的缺陷。但事件驱动模型倡导一个逻辑服务器应该应该能在单核CPU下表现得最优，以及占用更少的内存。与此相反，Apache的最初目的是以一切可利用的资源为代价充分高效管理并发和线程。事件驱动模型服务器避开了这种繁琐的设计而用最简洁高效的方式实现了可扩展性良好的服务器。
单线程也正符合云计算的平台的计算单位。很明显，一个单一的云实例，非常适合运行一个单一的Node.js的服务器，并使用负载均衡横向扩展。
事件驱动模型的出现，是为了解决传统服务器与网络工作负载的需求的不匹配，实现高度可伸缩服务器，并降低内存开销。事情驱动模型更改了连接到服务器的方式。所有的连接都由事件循环管理，每个连接触发一个在事件循环进程中运行的事件，而不是为每个连接生成一个新的 OS 线程，并为其分配一些配套内存。因此不用担心出现死锁，而且不会直接调用阻塞资源，而采用异步的方式来实现非阻塞式I/O。通过事件驱动模型在相同配置的服务器能接受更多的并发请求，实现可伸缩的服务器。
