I/O :
I/O Stack的流程(内核3.3版本的I/O Stack):
I/O Stack流图分为几大部分:
1>.direct I/O 的O_Direct调用
2>.Page Cache;
3>.VFS,也即文件系统、网络通信等
4>.Block I/O层
5>.I/O调度方式;
6>.SCSI处理层;
7>.磁盘硬件设备;
(来自thomas-krenn.com的图片)
TCP/UDP:
UDP就不同了, 面向报文形式, 系统是不会缓冲的, 也不会做优化的, Send的时候, 就会直接Send到网络上, 对方收不收到也不管, 所以这块数据总是能够能一包一包的形式接收到, 而不会出现前一个包跟后一个包都写到缓冲然后一起Send.
C10K问题的最大特点是:设计不够良好的程序,其性能和连接数及机器性能的关系往往 是非线性的。举个例子:如果没有考虑过C10K问题,一个经典的基于select的程序能在 旧服务器上很好处理1000并发的吞吐量,它在2倍性能新服务器上往往处理不了并发2000的吞吐量。 这是因为在策略不当时,大量操作的消耗和当前连接数n成线性相关。会导致单个任务的资源消耗和当前连接数的关系会是O(n)。而服务程序需要同时对数以万计的socket进 行I/O处理,积累下来的资源消耗会相当可观,这显然会导致系统吞吐量不能和机器性 能匹配。为解决这个问题,必须改变对连接提供服务的策略。
主要有两方面的策略:
1. Serve one client with each thread/process, and use blocking I/O 。Apache、ftpd等都是这种工作模式。
2. Serve many clients with single thread, and use nonblocking I/O and readiness notification 。优点在于实现较简单,方便移植,也 能提供足够的性能;缺点在于无法充分利用多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和经典模型,降低了程序的可移植性。