关于RoR的性能研究 二

参考:《Netty权威指南》(李版)1.1.2

其实我并不关心Puma是怎么安排进程/线程的,上文只是验证了RoR框架是支持多进程/多线程部署的。

现在我们着重研究下Passenger + Nginx部署RoR的网络IO模型和进程/线程安排形况。

为了更好地理解,我们通过Passenger + Apache的对比来验证。

先看看理论方面

网络IO模型

Nginx:epoll,IO复用

* 实际上这种说法不准确,Nginx的实现依赖的是Linux2.6以上内核的epoll或是BSD内核的kqueue 

Apache:select,IO复用

既然都是IO复用模型,那这里就要简要对比一下epoll和select

1、支持单进程打开的FD(socket文件描述符)数量

select最大的缺陷就是单个进程打开的FD数量严重受限。这个数量由宏FD_SETSIZE设置,默认是1024,这就意味着通常情况下单进程select监视的socket将不超过1024个。而想修改这个宏必须重新编译内核,并且修改之后会带来网络效率的下降。

Apache选择的方案是采用多进程,但是进程维护是需要代价的,而且进程间通信也有代价。

epoll则没有这个限制,epoll支持的FD数量是操作系统的最大句柄数(可以通过cat /proc/sys/fs/file-max来查看)。这个值跟系统内存关系较大,1GB内存的机器上这个值大约是10万。

2、IO效率与FD数量的关系

select/poll还有一个缺陷就是当被监视的socket很多的时候,由于大部分情况下只有少数socket处于活跃状态,但是select/poll的每次调用都会对全部的socket进行线性扫描,这样会导致IO效率呈线性下降。

对于epoll来说,由于只有活跃的socket才会主动调用callback函数,所以epoll只会对活跃的socket进行操作。从这点上来说epoll实现的是一种伪AIO(伪异步IO)。

3、内核与用户空间的消息传递

无论哪种IO,最终都需要将内核数据拷贝到用户空间。epoll是通过内核和用户间mmap同一块内存来实现的,所以效率更高。

这就意味着Nginx比Apache拥有更加出色的并发能力,Nginx采用epoll是其拥有高并发能力的根本原因。

进程/线程

Nginx:异步多进程,每个进程同时处理多个(数万个)连接请求

Apache:同步多进程,每个进程处理一个连接请求

多核CPU支持

Nginx:支持

Apache:不支持

相关文章
相关标签/搜索