epoll

小程序功能：简单的父子进程之间的通讯，子进程负责每隔1s不断发送"message"给父进程，不需要跑多个应用实例，不需要用户输入。 首先上代码 #include<assert.h> #include<signal.h> #include<stdio.h> #include<sys/epoll.h> #include<sys/time.h> #include<sys/wait.h> #include<unistd.h> int fd[2]; int* write_fd; int* read_fd; const char msg[] = {'m','e','s','s','a','g','e'}; void SigHandler(int){ size_t bytes = write(*write_fd, msg, sizeof(msg)); printf("children process msg have writed : %ld bytes\n", bytes); } void ChildrenProcess() { struct sigaction sa; sa.sa_flags = 0; sa.sa_handler = SigHandler; sigaction(SIGALRM, &sa, NULL); struct itimerval tick = {0}; tick.it

目录 高性能网络通讯原理 前言 I/O访问 I/O模型 同步阻塞 select模型/poll模型 epoll模型 异步I/O模型 I/O线程模型 Reactor模型 Proactor模型 总结 参考文档 高性能网络通讯原理 前言 本来想对netty的源码进行学习和探究，但是在写netty之前许多底层的知识和原理性的东西理解清楚，那么对学习网络通讯框架的效果则会事半功倍。 本篇主要探讨高性能网络通讯框架的一些必要知识和底层操作系统相关的原理。在探讨如何做之前，我们先讨论下为什么要做。 随着互联网的高速发展，用户量呈指数形式递增，从原来的PC普及到现在的移动设备普及。用户量都是千万甚至亿为单位计算，尤其是实时通讯软件，在线实时互动的应用出现，在线用户数从原来的几十上百到后来的上万甚至上千万。单台服务的性能瓶颈和网络通讯瓶颈慢慢呈现。应用架构从单应用到应用数据分离，再到分布式集群高可用架构。单台服务的性能不足可以通过构建服务集群的方式水平扩展，应用性能瓶颈被很好的解决。但是横向扩展带来了直接的经济成本。 一个高性能的网络通讯框架从硬件设备到操作系统内核以及用户模式都需要精心设计。从底层的I/O访问，到操作系统内核的I/O模型，线程调度以及用户框架都需要精心设计，只要有任何地方有疏漏都会出现短板效应。 I/O访问 当我们在读取socket数据时，虽然我们在代码仅仅是调用了一个 Read

I am working on a monothreaded process applet which creates a proxy virtual device (more precisely a virtual Xbox 360 pad); I do manage to create it with the uinput interface, I set it up properly and it works just fine. In order to feed commands to this virtual device , I read events from another real interface (in this case a PS3 pad), and I open the real device file with these flags: fd = open("/dev/input/event22", O_RDONLY); // open the PS3 pad The main loop is something like (minus error checking): while(run) { input_event ev = {0}; read(fd, &ev, sizeof(struct input_event)); // convert

在nginx之前 同步异步阻塞非阻塞、并发并行 1）同步与异步 同步：当一个同步调用发出后，调用者要一直等待调用的结果返回，才能进行后续的执行 异步：当一个异步调用发出后，调用者不必一直等待调用结果的返回；异步调用要获取结果，有两种方式： 主动轮询异步调用的结果 被调用方通过callback（回调通知）来通知调用方调用结果 2）阻塞与非阻塞 阻塞与非阻塞的重点在于进/线程等待消息时的行为：在等待消息的时候，当前线程是挂起状态，还是非挂起状态 阻塞：调用发出后，在消息返回前，当前线程被挂起，直到有消息返回，当前进/线程才会被激活 非阻塞：调用发出后，不会阻塞当前进/线程，而会立即返回 总结：同步与异步，重点在于消息通知的方式；阻塞与非阻塞，重点在等待消息时的行为。 Nginx采用异步非阻塞的方式工作。跟Linux中的epoll模型有关。 3）并发与并行 并发（concurrency）和并行（parallellism）是： 解释一：并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。 解释二：并行是在不同实体上的多个事件，并发是在同一实体上的多个事件。 解释三：在一台处理器上“同时”处理多个任务，在多台处理器上同时处理多个任务。 如hadoop分布式集群 所以并发编程的目标是充分的利用处理器的每一个核，以达到最高的处理性能 epoll I

In LDD3, i saw such codes static unsigned int scull_p_poll(struct file *filp, poll_table *wait) { struct scull_pipe *dev = filp->private_data; unsigned int mask = 0; /* * The buffer is circular; it is considered full * if "wp" is right behind "rp" and empty if the * two are equal. */ down(&dev->sem); poll_wait(filp, &dev->inq, wait); poll_wait(filp, &dev->outq, wait); if (dev->rp != dev->wp) mask |= POLLIN | POLLRDNORM; /* readable */ if (spacefree(dev)) mask |= POLLOUT | POLLWRNORM; /* writable */ up(&dev->sem); return mask; } But it says poll_wait won't wait and will return immediately. Then

http://www.phpzixue.cn/detail1174.shtml Apache与Nginx的优缺点比较 1、nginx相对于apache的优点： 轻量级，同样起web 服务，比apache 占用更少的内存及资源 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速啊 apache 相对于nginx 的优点： rewrite ，比nginx 的rewrite 强大 模块超多，基本想到的都可以找到 少bug ，nginx 的bug 相对较多 超稳定 存在就是理由，一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。后者的各种功能模块实现得比前者，例如ssl 的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由，但并不是所有的情况下都是epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的select 模型或许比epoll 更高性能。当然，这只是根据网络IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。 2、作为 Web 服务器：相比 Apache，Nginx

nginx 相对 apache 的优点： 轻量级，同样起web 服务，比apache 占用更少的内存及资源抗并发， nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速啊 apache 相对nginx 的优点： rewrite ，比nginx 的rewrite 强大 模块超多，基本想到的都可以找到 少bug ，nginx 的bug 相对较多 超稳定 存在就是理由，一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。后者的各种功能模块实现得比前者，例如ssl 的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由，但并不是所有的情况下都是epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的select 模型或许比epoll 更高性能。当然，这只是根据网络IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。 1、作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下

Nginx 轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源 抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比 apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 ，而 apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。 nginx 处理静态文件好，静态处理性能比 apache 高三倍以上 nginx 的设计高度模块化，编写模块相对简单 nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，apache 配置复杂 ，重启的时候发现配置出错了，会很崩溃 nginx 作为负载均衡服务器，支持 7 层负载均衡 nginx 本身就是一个反向代理服务器，而且可以作为非常优秀的邮件代理服务器 启动特别容易, 并且几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动，还能够不间断服务的情况下进行软件版本的升级 社区活跃，各种高性能模块出品迅速 Apache apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache apache 发展到现在，模块超多，基本想到的都可以找到 apache 更为成熟，少 bug