code_tin

从头编写高性能服务程序8-多进程非阻塞epoll-prefork
上一个版本在accept的位置仍旧会被阻塞 这样当一个链接进来的时候就会产生一个新的进程 进程的不断开启和释放会造...
扫描右侧二维码阅读全文
31
2010/01

从头编写高性能服务程序8-多进程非阻塞epoll-prefork

上一个版本在accept的位置仍旧会被阻塞
这样当一个链接进来的时候就会产生一个新的进程
进程的不断开启和释放会造成很大的性能影响
而一般Apache和Nginx的做法就是先产生N个进程用以备用
当有实际链接的时候,就由这些进程获取并进行处理
(注:Nginx的线程模式只在Windows下有效,在Linux下是使用进程模型的)
这样我们就有两个地方需要改造

第一个是将listen端口也变为非阻塞
这样当有新链接进来的时候我们得到通知才去处理
这样accept调用就不会被阻塞在进程导致进程无法进行后续的工作

第二是进程一启动之后就fork N个进程
这些进程启动之后就自行获取各自的accept
然后自行处理各自获取的链接并管理其生命周期内的所有内容

将listen也放置到epoll中
就需要在每次获得epoll events的时候判断下
这个events是前面放进去的listen,如果是listen就要accept
如果是accept的就进行数据传输处理

#include #include #include #include #include #include #include int main(){ int listen_fd,accept_fd,flag; struct sockaddr_in my_addr,remote_addr; if ((listen_fd = socket(AF_INET, SOCK_STREAM, 0)) == -1){ perror("create socket error"); exit(1); } if (setsockopt(listen_fd,SOL_SOCKET,SO_REUSEADDR ,(char *)&flag,sizeof(flag)) == -1){ perror("setsockopt error"); } int flags = fcntl(listen_fd, F_GETFL, 0); fcntl(listen_fd, F_SETFL, flags|O_NONBLOCK); my_addr.sin_family = AF_INET; my_addr.sin_port = htons(3389); my_addr.sin_addr.s_addr = INADDR_ANY; bzero(&(my_addr.sin_zero), 8); if (bind(listen_fd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_in)) == -1) { perror("bind error"); exit(1); } if (listen(listen_fd,1) == -1){ perror("listen error"); exit(1); } int pid=-1; int addr_len = sizeof(struct sockaddr_in); int max_process_num = 3; int child_id; int i; int child_process_status; for(i = 0; i < max_process_num; i++){ if(pid != 0){ pid = fork(); } else{ child_id = i; } } if(pid == 0){ int accept_handles = 0; struct epoll_event ev,events[20]; int epfd = epoll_create(256); int ev_s = 0; ev.data.fd = listen_fd; ev.events = EPOLLIN|EPOLLET; epoll_ctl(epfd,EPOLL_CTL_ADD,listen_fd,&ev); for(;;){ ev_s = epoll_wait( epfd,events, 20, 500 ); int i = 0; for(i = 0; i

Last modification:November 26th, 2018 at 04:16 pm
If you think my article is useful to you, please feel free to appreciate

4 comments

  1. keily

    你好!谢谢分享!
    以后能不能多写点注释呢?谢谢!

  2. kitty

    非常感谢回复,抱歉查看晚了。
    现在处于初学阶段,看的还不是很明白。
    可以这样理解么,具体唤醒哪一个进程是由内核去处理,
    不需要自己判断处理?如果这样的话,内核是用什么机制去判断的呢?

  3. 代码罐头

    这个问题就是多进程里面的群惊现象
    当所有进程都阻塞在listen端口时
    一旦系统获得listen端口的状态变化
    会把所有的线程都唤醒,而只有一个获取后进行处理
    其他的在被阻塞后继续沉睡
    不过在Linux 2.4以后这个群惊的现象已经被内核给处理掉了
    实际测试下来只有一个进程会被再次唤醒,而其他保持阻塞,
    这样阻塞在listen端口其实效率不比阻塞在同享锁差.毕竟调度是在内核级别的.

  4. kitty

    楼主你好,我最近也在写HTTP服务器的程序,看了你的这系列的文章,写得很仔细。
    这篇的多进程,我有个不太清楚的地方,这里的多个进程都是使用同一个listen_fd, 那么当多个进程都在epoll的时候,若有请求发生,会是哪一个进程得到该请求的事件,进而处理呢?

Leave a Comment