Nginx中并发性能相关配置参数说明

worker_processes：开启worker进程的数目，通常可设置为CPU核心的倍数。在不清楚的情况下，可设置成一倍于CPU核心数或auto(Nginx将自动发现CPU核心数)。

worker_connections：单个worker可处理并发连接的上限，但实际并发连接数能否达到这个值还与系统其他资源限制有关。当前Nginx实例可处理的并发连接数为 worker_processes * [b]worker_connections[/b]。

worker_rlimit_nofile：worker可打开文件数上限(每个套接字打开一个文件描述符)，worker_rlimit_nofile类似于系统配置ulimit -n(不过ulimit -n设置的最大值不能超过65536，且只能在当前shell环境中生效，重启后无效)。

limit_conn_zone：定义连接域，通常要与limit_conn配合使用。

limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size: 10m

limit_conn：为指定域中的每个key配置并发连接数，当实际连接请求数超出该值则拒绝。

limit_conn_zone $binary_remote_addr zone=addr:10m;#shared memory size 10m

server {
...
limit_conn addr 1;#allow only one connection per an IP address at a time.
}

但要记住的是，

In HTTP/2 and SPDY, each concurrent request is considered a separate connection.

limit_conn_status：当连接请求被拒绝后返回的状态码，默认503。

limit_req_zone：它是基于漏桶(Leaky Bucket)算法实现的，

http {
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/m;
...
server {
...
location /search/ {
limit_req zone=one burst=5 nodelay;
}

limit_req：来不及处理的请求被延迟执行，直到它们的数量超过burst(漏桶的最大容量，默认为0)，即溢出(Nginx将拒绝该请求)；在上例中，nodelay表示在记时一分钟内，即使请求未溢出，只要是超出了10个后也直接拒绝。

limit_req_status：当请求被拒绝后返回的状态码，默认503。

limit_rate：这是ngx_http_core_module提供的功能，用于限制Nginx的下载速率。如果是对代理限速，也可以使用X-Accel-Limit-Rate响应头。

location /download {
limit_rate_after 10m;
limit_rate 128k;
}

limit_rate_after：通常与limit_rate一起使用。在上例中，10m以前不限速，10m以后才限制下载速率。

accept_mutex：默认为off，V1.11.3前默认为on， There is no need to enable accept_mutex on systems that support the EPOLLEXCLUSIVE flag (1.11.3) or when using reuseport. 当一个新连接到来时，所有可用的worker将从等待状态被唤醒，最终却只有一个worker能接受并处理连接，这就是所谓的惊群现象；如果这种现象每秒重复多次，将导致服务器性能下降，因为所有被唤醒的worker都在占用CPU时间，而增加了非生产性CPU周期和未使用的上下文切换。但Linux系统底层已经解决了这个问题，Nginx 自1.11.3开始支持EPOLLEXCLUSIVE flag，因此accept_mutex默认变为off。

events {
accept_mutex on;#worker processes will accept new connections by turn.
}

accept_mutex_delay：当启用accept_mutex时，只有一个具有互斥锁的worker接受连接，其他worker则轮流等待accept_mutex_delay指定的时间。

multi_accept：默认为off。值为on使得worker能够在获得新连接通知时接受所有连接并放到监听队列中，值为off使得worker将逐个接受新连接。

thread_pool：采用asynchronous file I/O (AIO)，多线程读写不锁worker。



上图展示了Nginx的事件队列是在循环中顺序执行的，可能存在又长又重的操作(阻塞操作)导致事件处理循环卡住，其他事件必须等待这个操作执行完毕，因此而引入线程池；但在cache情景下，线程池并不会带来性能提升，反而应避免使用。有人说Nginx引入线程池而得9倍性能提升。

Syntax:	thread_pool name threads=number [max_queue=number];
Default: thread_pool default threads=32 max_queue=65536;
Context: main
This directive appeared in version 1.7.11.

keepalive： 在每一个worker进程的cache中创建一个到upstream的空闲keepalive连接池。如果keepalive池中的连接用完，Nginx依然可以向upstream发出更多的新连接，连接池只是起到缓存空闲keepalive连接的作用。It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well.

upstream fastcgi_backend {
server 127.0.0.1:9000;

keepalive 8;#连接池最大容量8。When this number is exceeded, the least recently used connections are closed.
}

server {
...

location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_keep_conn on;
...
}
}