epoll的基本概念和C10K问题

问题由来

网络服务在处理数以万计的客户端连接时,往往出现效率低下甚至完全瘫痪,这被称为C10K问题。随着互联网的迅速发展,越来越多的网络服务开始面临C10K问题,作为大型网站的开发人员有必要对C10K问题有一定的了解。(本文的主要参考文献是 http://www.kegel.com/c10k.htmls。) C10K问题的最大特点是:设计不够良好的程序,其性能和连接数与机器性能的关系往往是非线性的。举个例子:如果没有考虑过C10K问题,一个经典的基于select的程序能在旧服务器上很好处理1000并发的吞吐量,它在2倍性能新服务器上往往处理不了并发2000的吞吐量。这是因为在策略不当时,大量操作的消耗和当前连接数n成线性相关。会导致单个任务的资源消耗和当前连接数的关系会是O(n)。而服务程序需要同时对数以万计的socket进行I/O处理,积累下来的资源消耗会相当可观,这显然会导致系统吞吐量不能和机器性能匹配。为解决这个问题,必须改变对连接提供服务的策略。

基本策略:

主要有两方面的策略:

1.应用软件以何种方式和操作系统合作,获取I/O事件并调度多个socket上的I/O操作;

2.应用软件以何种方式处理任务和线程/进程的关系。前者主要有阻塞I/O、非阻塞I/O、异步I/O这3种方案,后者主要有每任务1进程、每任务1线程、单线程、多任务共享线程池以及一些更复杂的变种方案。常用的经典策略如下:

  1. Serve one client with each thread/process, and use blocking I/O这是小程序和java常用的策略,对于交互式的长连接应用也是常见的选择(比如BBS)。这种策略很能难足高性能程序的需求,好处是实现极其简单, 容易嵌入复杂的交互逻辑。Apache、ftpd等都是这种工作模式。

  2. Serve many clients with single thread, and use nonblocking I/O and readiness notification 这是经典模型,datapipe等程序都是如此实现的。优点在于实现较简单,方便移植,也能提供足够的性能;缺点在于无法充分利用多CPU的机器。尤其是程序本身没有复杂的业务逻辑时。

  3. Serve many clients with each thread, and use nonblocking I/O and readiness notification 对经典模型2的简单改进,缺点是容易在多线程并发上出bug,甚至某些OS不支持多线程操作readiness notification。

  4. Serve many clients with each thread, and use asynchronous I/O 在有AI/O支持的OS上,能提供相当高的性能。不过AI/O编程模型和经典模型差别相当大,基本上很难写出一个框架同时支持AI/O和经典模型,降低了程序的可移植性。在Windows上,这基本上是唯一的可选方案。
    本文主要讨论模型2的细节,也就是在模型2下应用软件如何处理Socket I/O。

    https://blog.csdn.net/shenya1314/article/details/73691088