Nginx百万并发的优化之道

今天的分享 Nginx的性能优化，希望能给大家带来一些系统化思考，帮助大家更有效地去做Nginx。

1. 优化方法论

今天我的分享重点会看两个问题：

第一，保持并发连接数，怎么样做到内存有效使用

第二，在高并发的同时保持高吞吐量的重要要点

实现层面主要是三方面优化，主要聚焦在应用、框架、内核

硬件限制刚刚也都讲过，可能有的同学也都听过，把网卡调到万兆、10G 或者40G 是最好的，

磁盘会根据成本的预算和应用场景来选择固态硬盘或者机械式硬盘，关注IOPS 或者 BPS。

CPU 是我们重点看的一个指标。

这一页重点来说下，实际上它是把操作系统的切换代价换到了进程内部，所以它从一个连接器到另外一个连接器的切换成本非常低，它性能很好，协程 Openresty 其实是一样的。

资源的高效使用，降低内存是对我们增大并发性是有帮助的，减少RTT、提升容量。

reuseport都是围绕着提升CPU的机核性。还有fastsocket，因为我之前在阿里云的时候还做过阿里云的网络，所以它其实能够带来很大的性能提升，但是它问题也很明显，把内核本身的那套东西绕过去了。

2. 请求的“一生”周期

下面首先会去聊一下怎么看“请求”，了解完这个以后再去看怎么优化就会很清楚了。

说这个之前必须再说一下Nginx的模块结构，像Nginx以外，任何一个外部框架都有个特点，

如果想形成整个生态必须允许第三方的代码接进来，构成一个序列，让一个请求挨个被模块共同处理。

那Nginx也一样，这些模块会串成一个序列，一个请求会被挨个的处理。

在核心模块里有两个，一个是steam 和 NGX。

2.1 请求到来

一个连接开始刚刚建立请求到来的时候会发生怎么样的事情，先是操作系统内核中有一个队列，等着我们的进程去系统调用，这时候因为有很多工作进程，谁会去调用呢，这有个负载均衡策略，下面有个PPT会专门说这个事情。

现在有一个事件模块，调用了epoll wait 这样的接口，accept 建立好一个新连接，这时会分配到连接内存池，这个内存池不同于所有的内存池，它在连接刚创建的时候会分配，什么时候会释放呢？

只有这个连接关闭的时候才会去释放。接下来就到了ngx模块，这时候会加一个定时器，60秒，就是在建立好连接以后60秒之内没有接到客户端发来的就自动关闭，如果60秒过来之后会去分配内存，读缓冲区。什么意思呢？

现在操作系统内核已经收到这个请求了，但是我的应用程序处理不了，因为没有给它读到用户态的内存里去，所以这时候要分配内存，从连接内存池这里分配，那要分配多大呢？会扩到1K。

2.2 收到请求

当收到请求以后，接收uri 和 header，分配请求内存池，这时候 request pool size是4K，大家发现是不是和刚才的有一个8倍的差距，这是因为利用态的内存是非常消耗资源。

再看为什么会消耗资源，首先会用状态机解去形容，所谓状态机解就是把它当做一个序列，一个支节一个支节往下解，如果发现换行了那就是请求行解完了；

但如果这个请求特别长的时候，就会去再分配更大的，刚刚1K不够用了，为什么是4乘8K呢？就是因为当1K不够了不会一次性分配 32K，而是一次性分配8K。如果 8K以后还没有解析到刚才的标识符，就会分配第二个8K。

我之前收到的所有东西都不会释放，只是放一个指针，指到 url 或者指到那个协议，标识它有多长就可以了。

接下来解决header，这个流程一模一样的没有什么区别，这时候还会有一个不够用的情况，当我接收完所有的header以后，会把刚刚的定时器给移除，移除后接下来做11个阶段的处理，也就是说刚刚所有的外部服务器都是通过很多的模块串成在一起处理一个请求的。

像刚刚两页PPT都在说蓝色的区域，那么请求接下来11个阶段是什么意思呢？

这个黄色的、绿色的，还有右边这个都是在11阶段之中。

这11个阶段大家也不用记，非常简单，只要掌握三个关键词就可以。

刚刚读完 header 要做处理，所以这时候第一阶段是 post-read。接下来会有rewrite，还有access和preaccess。

先看左手边，当我们下载完 Nginx 源码编以后会有一个referer，所有的第三方数据都会在这里呈现有序排列，这些序列中并不是简单的一个请求给它再给它，先是分为11个阶段，每个阶段之内大家是有序一个个往后来的，但在11个阶段中是按阶段来的。

我把它分解一下，第一个referer这阶段有很多模块，后面这是有序的。

百万并发下 Nginx 的优化之道

这个图比刚刚的图多了两个关键点，第一到了某一个模块可以决定继续向这序列后的模块执行，也可以说直接跳到下个阶段，但不能说跳多个阶段。

第二是生成了向客户端反映的响应，这时候要对响应做些处理，这里是有序的，先做缩略图再做压缩，所以它是有严格顺序的。

2.3 请求的反向代理

请求的反向代理，反向代理这块是我们Nginx的重点应用场景，因为Nginx会考虑一种场景，我不知道大家有没有用过，客户端走的是公网，所以网络环境非常差，网速非常慢，如果简单用一个缓冲区从客户端收一点发给上游服务器，那上游服务器的压力会很大，因为上游服务器往往它的效率高，所以都是一个请求被处理完之前不会再处理下一个请求。

Nginx考虑到这个场景，它会先把整个请求全部收完以后，再向上游服务器建立连接，所以是默认第一个配置，就是proxy request buffering on，存放包体至文件，默认size是8K。那建立上游连接的时候会放timeout，60秒，添加超时定时器，也是60秒的。

发出请求（读取文体包件），如果向上游传一个很大的包体的话，那sizk就是8K。默认proxy limit rate是打开的，我们会先把这个请求全部缓存到端来，所以这时候有个8×8K，如果关掉的话，也就是从上游发一点就往下游发一点。知道这个流程以后，再说这里的话大家可以感觉到这里的内存消耗还是蛮大的。

百万并发下 Nginx 的优化之道

2.4 返回响应

返回响应，这里面其实内容蛮多的，我给大家简化一下，还是刚刚官方的那个包，这也是有顺的从下往上看，如果有大量第三方模块进来的话，数量会非常高。

第一个关键点是上面的header filter，上面是write filter，下面是postpone filter，这里还有一个copy filter，它又分为两类，一类是需要处理，一类是不需要处理的。

openresty的指令，第一代码是在哪里执行的，第二个是SDK。

3. 应用层优化

3.1 协议

做应用层的优化我们会先看协议层有没有什么优化，比如说编码方式、header每次都去传用Nginx的架构，以至于浪费了很多的流量。

我们可以改善http2，有很多这样的协议会有大幅度提升它的性能。

当然如果你改善http2了，会带来其他的问题，比如说http2必须走这条路线。

这条路线又是一个很大的话题，它涉及到安全性和性能，是互相冲突的东西。

3.2 压缩

我们希望“商”越大越好，压缩这里会有一个重点提出来的动态和静态，比如说我们用了拷贝，比如说可以从磁盘中直接由内核来发网卡，但一旦做压缩的话就不得不先把这个文件读到Nginx，交给后面的极内核去做一下处理。

keepalive长连接也是一样的，它也涉及到很多东西，简单来看这也就是附用连接。因为连接有一个慢启动的过程，一开始它的窗口是比较小，一次可能只传送很小的1K的，但后面可能会传送几十K，所以你每次新建连接它都会重新开始，这是很慢的。

当然这里还涉及到一个问题，因为Nginx内核它默认打开了一个连接空闲的时候，长连接产生的作用也会下降。

提高内存使用率

刚刚在说具体的请求处理过程中已经比较详细的把这问题说清楚了，这里再总结一下，在我看来有一个角度，Nginx对下游只是必须要有的这些模块，client header、buffer size：1K，上游网络http包头和包体。

CPU通过缓存去取储存上东西的时候，它是一批一批取的，每一批目前是64字节，所以默认的是8K，如果你配了32它会给你上升到64，如果你配了65会升到128，因为它是一个一个序列化重组的，所以了解这个东西以后自己再配的时候就不会再犯问题。红黑树这里用的非常多，因为是和具体的模块相关。

3.4 限速

大部分我们在做分公司流控的时候，主要在限什么呢？主要限Nginx向客户端发送响应的速度。

这东西它非常好用，因为可以和Nginx定量连接在一起。

这不是限上游发请求的速度，而是在限从上游接响应的速度。

3.5 Worker间负载均衡

当时我在用0.6版本的时候那时候都在默认用这个，这个“锁”它是在用进程间同步方式去实现负载均衡，这个负载均衡怎么实现呢？就是保证所有的Worker进程，同一时刻只有一个Worker进程在处理距离，这里就会有好几个问题，绿色的框代表它的吞吐量，吞吐量不高，所以会导致第二个问题requests，也是比较长的，这个方差就非常的大。

如果把这个“锁”关掉以后，可以看到吞吐量是上升的，方差也在下降，但是它的时间在上升，为什么会出现这样的情况？因为会导致一个Worker可能会非常忙，它的连接数已经非常高了，但是还有其他的worker进程是很闲的。

如果用了requests，它会在内核层面上做负载均衡。这是一个专用场景，如果在复杂应用场景下开requests和不开是能看到明显变化的。