Hello!
2015-08-26 21:33 GMT+08:00 home_king:
> 众所周知，nginx分为多个worker子进程（一般每个CPU核一个worker），每个子进程独立去accept新连接。
> 一旦连接进入了某个worker之后，就只能被这个worker来处理了，这种连接的分配并不是以每个worker的工作负载来决定的。
事实上，如果某个 worker 进程较忙的话，就会由其他 worker 进程 accept 新连接。毕竟繁忙的 worker 响应
accept 事件的机会同比小一些。这里重要的是，禁掉 accept_mutex 配置，因为它会导致各 worker accept
新连接不够均衡：
http://nginx.org/en/docs/ngx_core_module.html#accept_mutex
同时不要开启 multi_accept 配置选项。
> 假设每个连接都是长连接，连接内的每个请求的处理都是CPU-bound类型，例如jpeg到webp的图片格式转换，图片大小是随机的，所以处理时间在1ms到10s的范围里浮动，那么这时候就有问题了，假设A
> worker和B worker都accept了10个连接，
你这里的前提就不成立，显然 CPU 使用率不同的 nginx worker 进程响应 accept 事件的频率也不尽相同。
> 对于http 2.0来说，每个连接内的多个请求可以独立进行处理和响应，上述问题会更加严重。
http 2.0 和 spdy 在协议设计上面确实很容易被攻击者滥用而导致服务器过载。所以一般最好在做累活的 nginx 之前放一个专用的
https 网关 nginx 实例（二者之间可以通过 unix domain socket 进行本地通信，这样也利于规避 SSL
计算引入的额外的阻塞效应）。
Regards,
-agentzh
P.S. 请先订阅 openresty 邮件列表再向列表邮箱发信。
