搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字

搜狗实验室技术交流文档Vol.
1:1C10K问题摘要编写连接数巨大的高负载服务器程序时,经典的多线程模式和select模式都不再适用.
应当抛弃它们,采用epoll/kqueue/dev_poll来捕获I/O事件.
最后简要介绍了AIO.
由来网络服务在处理数以万计的客户端连接时,往往出现效率低下甚至完全瘫痪,这被称为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.
Serveoneclientwitheachthread/process,anduseblockingI/O这是小程序和java常用的策略,对于交互式的长连接应用也是常见的选择(比如BBS).
这种策略很能难足高性能程序的需求,好处是实现极其简单,容易嵌入复杂的交互逻辑.
Apache、ftpd等都是这种工作模式.
2.
Servemanyclientswithsinglethread,andusenonblockingI/Oandreadinessnotification这是经典模型,datapipe等程序都是如此实现的.
优点在于实现较简单,方便搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字移植,也能提供足够的性能;缺点在于无法充分利用多CPU的机器.
尤其是程序本身没有复杂的业务逻辑时.
3.
Servemanyclientswitheachthread,andusenonblockingI/Oandreadinessnotification对经典模型2的简单改进,缺点是容易在多线程并发上出bug,甚至某些OS不支持多线程操作readinessnotification.
4.
Servemanyclientswitheachthread,anduseasynchronousI/O在有AI/O支持的OS上,能提供相当高的性能.
不过AI/O编程模型和经典模型差别相当大,基本上很难写出一个框架同时支持AI/O和经典模型,降低了程序的可移植性.
在Windows上,这基本上是唯一的可选方案.
本文主要讨论模型2的细节,也就是在模型2下应用软件如何处理SocketI/O.
select与poll最原始的同步阻塞I/O模型的典型流程如下:从应用程序的角度来说,read调用会延续很长时间,应用程序需要相当多线程来解决并发访问问题.
同步非阻塞I/O对此有所改进:经典的单线程服务器程序结构往往如下:do{GetReadinessNotificationofallsocketsDispatchreadyhandlestocorrespondinghandlersIf(readable){readthesocketIf(readdone)Handlerprocesstherequest搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字}if(writable)writeresponseif(nothingtodo)closesocket}while(True)非阻塞I/O模型的典型流程:其中关键的部分是readinessnotification,找出哪一个socket上面发生了I/O事件.
一般从教科书和例子程序中首先学到的是用select来实现.
Select定义如下:intselect(intn,fd_set*rd_fds,fd_set*wr_fds,fd_set*ex_fds,structtimeval*timeout);Select用到了fd_set结构,从manpage里可以知道fd_set能容纳的句柄和FD_SETSIZE相关.
实际上fd_set在*nix下是一个bit标志数组,每个bit表示对应下标的fd是不是在fd_set中.
fd_set只能容纳编号小于FD_SETSIZE的那些句柄.
FD_SETSIZE默认是1024,如果向fd_set里放入过大的句柄,数组越界以后程序就会垮掉.
系统默认限制了一个进程最大的句柄号不超过1024,但是可以通过ulimit-n命令/setrlimit函数来扩大这一限制.
如果不幸一个程序在FD_SETSIZE=1024的环境下编译,运行时又遇到ulimit–n>1024的,那就只有祈求上帝保佑不会垮掉了.
在ACE环境中,ACE_Select_Reactor针对这一点特别作了保护措施,但是还是有recv_n这样的函数间接的使用了select,这需要大家注意.
针对fd_set的问题,*nix提供了poll函数作为select的一个替代品.
Poll的接口如下:intpoll(structpollfd*ufds,unsignedintnfds,inttimeout);第1个参数ufds是用户提供的一个pollfd数组,数组大小由用户自行决定,因此避免了FD_SETSIZE带来的麻烦.
Ufds是fd_set的一个完全替代品,从select到poll的移植很方便.
到此为止,至少我们面对C10K,可以写出一个能work的程序了.
然而Select和Poll在连接数增加时,性能急剧下降.
这有两方面的原因:首先操作系统面对每次的select/poll操作,都需要重新建立一个当前线程的关心事件列表,并把搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字线程挂在这个复杂的等待队列上,这是相当耗时的.
其次,应用软件在select/poll返回后也需要对传入的句柄列表做一次扫描来dispatch,这也是很耗时的.
这两件事都是和并发数相关,而I/O事件的密度也和并发数相关,导致CPU占用率和并发数近似成O(n2)的关系.
epoll,kqueue,/dev/poll因为以上的原因,*nix的hacker们开发了epoll,kqueue,/dev/poll这3套利器来帮助大家,让我们跪拜三分钟来感谢这些大神.
其中epoll是linux的方案,kqueue是freebsd的方案,/dev/poll是最古老的Solaris的方案,使用难度依次递增.
简单的说,这些api做了两件事:1.
避免了每次调用select/poll时kernel分析参数建立事件等待结构的开销,kernel维护一个长期的事件关注列表,应用程序通过句柄修改这个列表和捕获I/O事件.
2.
避免了select/poll返回后,应用程序扫描整个句柄表的开销,Kernel直接返回具体的事件列表给应用程序.
在接触具体api之前,先了解一下边缘触发(edgetrigger)和条件触发(leveltrigger)的概念.
边缘触发是指每当状态变化时发生一个io事件,条件触发是只要满足条件就发生一个io事件.
举个读socket的例子,假定经过长时间的沉默后,现在来了100个字节,这时无论边缘触发和条件触发都会产生一个readreadynotification通知应用程序可读.
应用程序读了50个字节,然后重新调用api等待io事件.
这时条件触发的api会因为还有50个字节可读从而立即返回用户一个readreadynotification.
而边缘触发的api会因为可读这个状态没有发生变化而陷入长期等待.
因此在使用边缘触发的api时,要注意每次都要读到socket返回EWOULDBLOCK为止,否则这个socket就算废了.
而使用条件触发的api时,如果应用程序不需要写就不要关注socket可写的事件,否则就会无限次的立即返回一个writereadynotification.
大家常用的select就是属于条件触发这一类,以前本人就犯过长期关注socket写事件从而CPU100%的毛病.
epoll的相关调用如下:intepoll_create(intsize)intepoll_ctl(intepfd,intop,intfd,structepoll_event*event)intepoll_wait(intepfd,structepoll_event*events,intmaxevents,inttimeout)epoll_create创建kernel中的关注事件表,相当于创建fd_set.
epoll_ctl修改这个表,相当于FD_SET等操作epoll_wait等待I/O事件发生,相当于select/poll函数epoll完全是select/poll的升级版,支持的事件完全一致.
并且epoll同时支持边缘触发和条件触发,一般来讲边缘触发的性能要好一些.
这里有个简单的例子:structepoll_eventev,*events;intkdpfd=epoll_create(100);ev.
events=EPOLLIN|EPOLLET;//注意这个EPOLLET,指定了边缘触发ev.
data.
fd=listener;epoll_ctl(kdpfd,EPOLL_CTL_ADD,listener,&ev);for(;;){nfds=epoll_wait(kdpfd,events,maxevents,-1);搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字for(n=0;ndata.
fd==listener){client=accept(listener,(structsockaddr*)&local,&addrlen);if(client<0){perror("accept");continue;}setnonblocking(client);ev.
events=EPOLLIN|EPOLLET;ev.
data.
fd=client;if(epoll_ctl(kdpfd,EPOLL_CTL_ADD,client,&ev)<0){fprintf(stderr,"epollsetinsertionerror:fd=%d0,client);return-1;}}elsedo_use_fd(events[n].
data.
fd);}}简单介绍一下kqueue和/dev/pollkqueue是freebsd的宠儿,kqueue实际上是一个功能相当丰富的kernel事件队列,它不仅仅是select/poll的升级,而且可以处理signal、目录结构变化、进程等多种事件.
Kqueue是边缘触发的/dev/poll是Solaris的产物,是这一系列高性能API中最早出现的.
Kernel提供一个特殊的设备文件/dev/poll.
应用程序打开这个文件得到操纵fd_set的句柄,通过写入pollfd来修改它,一个特殊ioctl调用用来替换select.
由于出现的年代比较早,所以/dev/poll的接口现在看上去比较笨拙可笑.
C++开发:ACE5.
5以上版本提供了ACE_Dev_Poll_Reactor封装了epoll和/dev/poll两种api,需要分别在config.
h中定义ACE_HAS_EPOLL和ACE_HAS_DEV_POLL来启用.
Java开发:JDK1.
6的Selector提供了对epoll的支持,JDK1.
4提供了对/dev/poll的支持.
只要选择足够高的JDK版本就行了.
异步I/O以及Windows和经典模型不同,异步I/O提供了另一种思路.
和传统的同步I/O不同,异步I/O允许进程发起很多I/O操作,而不用阻塞或等待任何操作完成.
稍后或在接收到I/O操作完成的通知时,进程就可以检索I/O操作的结果.
搜狐公司研发中心版权所有,仅供技术交流,转载请保留上述文字异步非阻塞I/O模型是一种处理与I/O重叠进行的模型.
读请求会立即返回,说明read请求已经成功发起了.
在后台完成读操作时,应用程序然后会执行其他处理操作.
当read的响应到达时,就会产生一个信号或执行一个基于线程的回调函数来完成这次I/O处理过程.
异步I/O模型的典型流程:对于文件操作而言,AIO有一个附带的好处:应用程序将多个细碎的磁盘请求并发的提交给操作系统后,操作系统有机会对这些请求进行合并和重新排序,这对同步调用而言是不可能的——除非创建和请求数目同样多的线程.
LinuxKernel2.
6提供了对AIO的有限支持——仅支持文件系统.
libc也许能通过来线程来模拟socket的AIO,不过这对性能没意义.
总的来说Linux的aio还不成熟Windows对AIO的支持很好,有IOCP队列和IPCP回调两种方式,甚至提供了用户级异步调用APC功能.
Windows下AIO是唯一可用的高性能方案,详情请参考MSDN.
待续ThreadPool与PipeLineSendfile等技巧节省用户空间和系统空间的来回拷贝Timer技巧alloca与内存池Lock技巧