NGINX引入线程池 性能提升9倍

1. 引言

正如我们所知，NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的socket模式下，并使用了epoll 和 kqueue这样有效的方法。

因为满负载进程的数量很少（通常每核CPU只有一个）而且恒定，所以任务切换只消耗很少的内存，而且不会浪费CPU周期。通过NGINX本身的实例，这种方法的优点已经为众人所知。NGINX可以非常好地处理百万级规模的并发请求。

每个进程都消耗额外的内存，而且每次进程间的切换都会消耗CPU周期并丢弃CPU高速缓存中的数据。

但是，异步、事件驱动方法仍然存在问题。或者，我喜欢将这一问题称为“敌兵”，这个敌兵的名字叫阻塞（blocking）。不幸的是，很多第三方模块使用了阻塞调用，然而用户（有时甚至是模块的开发者）并不知道阻塞的缺点。阻塞操作可以毁掉NGINX的性能，我们必须不惜一切代价避免使用阻塞。

即使在当前官方的NGINX代码中，依然无法在全部场景中避免使用阻塞，NGINX1.7.11中实现的线程池机制解决了这个问题。我们将在后面讲述这个线程池是什么以及该如何使用。现在，让我们先和我们的“敌兵”进行一次面对面的碰撞。

2. 问题

首先，为了更好地理解这一问题，我们用几句话说明下NGINX是如何工作的。

通常情况下，NGINX是一个事件处理器，即一个接收来自内核的所有连接事件的信息，然后向操作系统发出做什么指令的控制器。实际上，NGINX干了编排操作系统的全部脏活累活，而操作系统做的是读取和发送字节这样的日常工作。所以，对于NGINX来说，快速和及时的响应是非常重要的。

工作进程监听并处理来自内核的事件

事件可以是超时、socket读写就绪的通知，或者发生错误的通知。NGINX接收大量的事件，然后一个接一个地处理它们，并执行必要的操作。因此，所有的处理过程是通过一个线程中的队列，在一个简单循环中完成的。NGINX从队列中取出一个事件并对其做出响应，比如读写socket。在多数情况下，这种方式是非常快的（也许只需要几个CPU周期，将一些数据复制到内存中），NGINX可以在一瞬间处理掉队列中的所有事件。

所有处理过程是在一个简单的循环中，由一个线程完成

但是，如果NGINX要处理的操作是一些又长又重的操作，又会发生什么呢？整个事件处理循环将会卡住，等待这个操作执行完毕。

因此，所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作。操作可以由于各种原因成为阻塞操作。例如，NGINX可能因长时间、CPU密集型处理，或者可能等待访问某个资源（比如硬盘，或者一个互斥体，亦或要从处于同步方式的数据库获得相应的库函数调用等）而繁忙。关键是在处理这样的操作期间，工作进程无法做其他事情或者处理其他事件，即使有更多的可用系统资源可以被队列中的一些事件所利用。

我们来打个比方，一个商店的营业员要接待他面前排起的一长队顾客。队伍中的第一位顾客想要的某件商品不在店里而在仓库中。这位营业员跑去仓库把东西拿来。现在整个队伍必须为这样的配货方式等待数个小时，队伍中的每个人都很不爽。你可以想见人们的反应吧？队伍中每个人的等待时间都要增加这些时间，除非他们要买的东西就在店里。

队伍中的每个人不得不等待第一个人的购买

在NGINX中会发生几乎同样的情况，比如当读取一个文件的时候，如果该文件没有缓存在内存中，就要从磁盘上读取。从磁盘（特别是旋转式的磁盘）读取是很慢的,而当队列中等待的其他请求可能不需要访问磁盘时，它们也得被迫等待。导致的结果是，延迟增加并且系统资源没有得到充分利用。

一个阻塞操作足以显著地延缓所有接下来的操作

一些操作系统为读写文件提供了异步接口，NGINX可以使用这样的接口（见AIO指令）。FreeBSD就是个很好的例子。不幸的是，我们不能在Linux上得到相同的福利。虽然Linux为读取文件提供了一种异步接口，但是存在明显的缺点。其中之一是要求文件访问和缓冲要对齐，但NGINX很好地处理了这个问题。但是，另一个缺点更糟糕。异步接口要求文件描述符中要设置O_DIRECT标记，就是说任何对文件的访问都将绕过内存中的缓存，这增加了磁盘的负载。在很多场景中，这都绝对不是最佳选择。

为了有针对性地解决这一问题，在NGINX 1.7.11中引入了线程池。默认情况下，NGINX 还没有包含线程池，但是如果你想试试的话，可以联系销售人员，NGINX R6是一个已经启用了线程池的构建版本。

现在，让我们走进线程池，看看它是什么以及如何工作的。

3. 线程池

让我们回到那个可怜的，要从大老远的仓库去配货的售货员那儿。这回，他已经变聪明了（或者也许是在一群愤怒的顾客教训了一番之后，他才变得聪明的？），雇用了一个配货服务团队。现在，当任何人要买的东西在大老远的仓库时，他不再亲自去仓库了，只需要将订单丢给配货服务，他们将处理订单，同时，我们的售货员依然可以继续为其他顾客服务。因此，只有那些要买仓库里东西的顾客需要等待配货，其他顾客可以得到即时服务。

传递订单给配货服务不会阻塞队伍

对NGINX而言，线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。
当工作进程需要执行一个潜在的长操作时，工作进程不再自己执行这个操作，而是将任务放到线程池队列中，任何空闲的线程都可以从队列中获取并执行这个任务。

工作进程将阻塞操作卸给线程池

那么，这就像我们有了另外一个队列。是这样的，但是在这个场景中，队列受限于特殊的资源。磁盘的读取速度不能比磁盘产生数据的速度快。不管怎么说，至少现在磁盘不再延误其他事件，只有访问文件的请求需要等待。

“从磁盘读取”这个操作通常是阻塞操作最常见的示例，但是实际上，NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

目前，卸载到线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。接下来，我们将对线程池进行测试（test）和基准测试（benchmark），在未来的版本中，如果有明显的优势，我们可能会卸载其他操作到线程池中。

4. 基准测试

现在让我们从理论过度到实践。我们将进行一次模拟基准测试（synthetic benchmark），模拟在阻塞操作和非阻塞操作的最差混合条件下，使用线程池的效果。

另外，我们需要一个内存肯定放不下的数据集。在一台48GB内存的机器上，我们已经产生了每文件大小为4MB的随机数据，总共256GB，然后配置NGINX，版本为1.9.0。

配置很简单：

worker_processes 16;

events {
    accept_mutex off;
}

http {
    include mime.types;
    default_type application/octet-stream;

    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;

    server {
        listen 8000;

        location / {
            root /storage;
        }
    }
}

如上所示，为了达到更好的性能，我们调整了几个参数：禁用了logging和accept_mutex，同时，启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间，因为NGINX不会尝试一次将整个文件发送出去，而是每次发送大小为512KB的块数据。

这台测试服务器有2个Intel Xeon E5645处理器（共计：12核、24超线程）和10-Gbps的网络接口。磁盘子系统是由4块西部数据WD1003FBYX 磁盘组成的RAID10阵列。所有这些硬件由Ubuntu服务器14.04.1 LTS供电。

为基准测试配置负载生成器和NGINX

客户端有2台服务器，它们的规格相同。在其中一台上，在wrk中使用Lua脚本创建了负载程序。脚本使用200个并行连接向服务器请求文件，每个请求都可能未命中缓存而从磁盘阻塞读取。我们将这种负载称作随机负载。

在另一台客户端机器上，我们将运行wrk的另一个副本，使用50个并行连接多次请求同一个文件。因为这个文件将被频繁地访问，所以它会一直驻留在内存中。在正常情况下，NGINX能够非常快速地服务这些请求，但是如果工作进程被其他请求阻塞的话，性能将会下降。我们将这种负载称作恒定负载。

性能将由服务器上ifstat监测的吞吐率（throughput）和从第二台客户端获取的wrk结果来度量。

现在，没有使用线程池的第一次运行将不会带给我们非常振奋的结果：

% ifstat -bi eth2
eth2
Kbps in  Kbps out
5531.24  1.03e 06
4855.23  812922.7
5994.66  1.07e 06
5476.27  981529.3
6353.62  1.12e 06
5166.17  892770.3
5522.81  978540.8
6208.10  985466.7
6370.79  1.12e 06
6123.33  1.07e 06

如上所示，使用这种配置，服务器产生的总流量约为1Gbps。从下面所示的top输出，我们可以看到，工作进程的大部分时间花在阻塞I/O上（它们处于top的D状态）：

top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89
Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers
KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem

  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME  COMMAND
 4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx
 4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx
 4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx
 4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx
 4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx
 4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx
 4638 vbart    20   0   
                      声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 
                      [邮箱地址] 删除