nginx使用连接池来增加对资源的利用率。
图1
每一个worker进程里面都会有一个ngx_cycle_t数据结构，该数据结构里面有一个connections数组，该数组就是我们要说的连接池。
一、connections
在nginx的官方文档中，worker_connections的介绍，从中我们可以知道这个连接池默认是512，也就是说该数组的长度是512，一个请求对应数组中一个元素，那么该worker进程能处理512个请求，这512中不仅包含客户端向服务器请求的数量，还包含服务器向上游服务器请求的数量。
也就是说，客户端向服务器发起一个请求，服务器将该请求转发给上游服务器，这个过程中有两次请求，占用connections中两个元素。
那么，其实这connections数组长度其实是不够用的，所以一般情况下，我们需要通过worker_rlimit_core去修改这个值。
二、read_events、write_events
每一个连接除了存放在connections中，还对应一个读时间和一个写事件，如图1，read_events中存放着读事件，write_events中存放着写事件，它们都是数组，并且长度与connections长度相同，一个请求和它的读事件、写事件是通过索引进行关联的。
所以在一个worker进程中，我们更改worker_connections的大小时，应该考虑到，当worker_connections数量增加，它所占用的内存就三倍增加。
那么一个请求要占用的具体内存是多少呢？
三、一个请求对应占用内存数
图2
如上图，每一个请求都对应一个ngx_connection_s，其占用232个字节，不同版本的浏览器，这个数字会有细微的差别。
每一个事件都对应一个ngx_event_s，其占用96个字节。
所以，一个请求占用的内存=232 + 96 * 2 = 424个字节。
ngx_event_s中有一个timer，当我们对读、写事件进行超时设置时，是对timer进行设置。
三、send
send是一个无符号的整型，它表达的是发送的字节数.
在打日志时，我们会用body_bytes_sent包含的是请求体中的字节数。
