多进程、多线程和I/O多路复用三种Web服务器模型

1、多进程模型的优缺点

2、多线程模型的优缺点

3、I/O多路复用的优缺点

---

1、多进程模型的优缺点

（1）优点：

• 1）每个进程互相独立，不影响主程序的稳定性，子进程崩溃没关系；
• 2）通过增加CPU，就可以容易扩充性能；
• 3）可以尽量减少线程加锁/解锁的影响，极大提高性能，就算是线程运行的模块算法效率低也没关系；
• 4）每个子进程都有2GB地址空间和相关资源，总体能够达到的性能上限非常大。

（2）缺点：

• 1）逻辑控制复杂，需要和主程序交互； 
• 2）需要跨进程边界，如果有大数据量传送，就不太好，适合小数据量传送、密集运算 ；
• 3）多进程调度开销比较大。

2、多线程模型的优缺点

（1）优点：

• 1）无需跨进程边界； 
• 2）程序逻辑和控制方式简单； 
• 3）所有线程可以直接共享内存和变量等； 
• 4）线程方式消耗的总资源比进程方式好； 

（2）缺点：

• 1）每个线程与主程序共用地址空间，受限于2GB地址空间； 
• 2）线程之间的同步和加锁控制比较麻烦； 
• 3）一个线程的崩溃可能影响到整个程序的稳定性； 
• 4）到达一定的线程数程度后，即使再增加CPU也无法提高性能；
• 5）线程能够提高的总性能有限，而且线程多了之后，线程本身的调度也是一个麻烦事儿，需要消耗较多的CPU 。

（3）如何减少上下文切换

    线程池的关键点是：

• 1）尽量减少线程切换和管理的开支；
• 2）最大化利用cpu。

    对于第一点，要求线程数尽量少，这样可以减少线程切换和管理的开支；对于第二点，要求尽量多的线程，以保证CPU资源最大化的利用。 所以：

• 对于任务耗时短的情况，要求线程尽量少，如果线程太多，有可能出现线程切换和管理的时间，大于任务执行的时间，那效率就低了；
• 对于耗时长的任务，要分是cpu任务，还是io等类型的任务。如果是cpu类型的任务，线程数不宜太多；但是如果是io类型的任务，线程多一些更好，可以更充分利用cpu。

    所以高并发，低耗时的情况：建议少线程，只要满足并发即可。例如并发100，线程池可能设置为10就可以。低并发，高耗时的情况：建议多线程，保证有空闲线程，接受新的任务。例如并发10，线程池可能就要设置为20。高并发高耗时：1要分析任务类型，2增加排队，3、加大线程数。

3、I/O多路复用的优缺点

（1）优点：

• 1）相比于多线程和多进程，I/O多路复用是在单一进程的上下文中的，当有多个并发连接请求时，多线程或者多进程模型需要为每个连接创建一个线程或者进程，而这些进程或者线程中大部分是被阻塞起来的。由于CPU的核数一般都不大，比如4个核要跑1000个线程，那么每个线程的时间槽非常短，而线程切换非常频繁。这样是有问题的。而使用I/O多路复用时，处理多个连接只需要1个线程监控就绪状态，对就绪的每个连接开一个线程处理（由线程池支持）就可以了，这样需要的线程数大大减少，减少了内存开销和上下文切换的CPU开销。
• 2）整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动。

（2）缺点：

•  单线程模型不能有阻塞，一旦发生任何阻塞（包括计算机计算延迟）都会使得这个模型不如多线程。另外，单线程模型不能很好的利用多核cpu。

（3）三种I/O多路复用方式介绍（参考这里）：

  select的优缺点：

  优点： 

•  1）select的可移植性好，在某些unix下不支持poll. 
•  2）select对超时值提供了很好的精度，精确到微秒，而poll式毫秒。 

  缺点： 

•  1）单个进程可监视的fd数量被限制，默认是1024。 
•  2）需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。 
•  3）对fd进行扫描时是线性扫描，fd剧增后，IO效率降低，每次调用都对fd进行线性扫描遍历，随着fd的增加会造成遍历速度慢的问题。 
•  4）select函数超时参数在返回时也是未定义的，考虑到可移植性，每次超时之后进入下一个select之前都要重新设置超时参数。

  poll的优缺点：

  优点： 

• 1）不要求计算最大文件描述符+1的大小。 
• 2）应付大数量的文件描述符时比select要快。 
• 3）没有最大连接数的限制是基于链表存储的。 

  缺点： 

• 1）大量的fd数组被整体复制于内核态和用户态之间，而不管这样的复制是不是有意义。 
• 2）同select相同的是调用结束后需要轮询来获取就绪描述符。

  epoll的优缺点（epoll详解）：

    1）支持一个进程打开大数目的socket描述符(FD) 

    select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完 美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。 

    2）IO效率不随FD数目增加而线性下降 

    传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是”活跃”的， 但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对”活跃”的socket进行 操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有”活跃”的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个”伪”AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。  

参考：https://blog.csdn.net/wan_hust/article/details/38441455

           https://blog.csdn.net/jyy305/article/details/73012706