nginx--worker_processes压测文档

本文通过ab工具对Nginx结合Lua的服务进行压力测试,详细记录了不同worker数量下,包括2个、4个和8个worker的并发500和1000请求时的各项性能指标,如请求速度、响应时间、传输速率等,并分析得出双核机器下worker设置为2个时性能最优。

注:服务是nginx+lua,在lua层有大量的业务逻辑,使用ab压测的,在公司虚拟化机器压测的,数据只做参考

cpu信息:两个逻辑核

2个worker压测

配置:

worker_processes  2;
worker_cpu_affinity 01 10;

并发500压测数据:

Concurrency Level:      500
Time taken for tests:   11.068 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    451.75 [#/sec] (mean)
Time per request:       1106.817 [ms] (mean)
Time per request:       2.214 [ms] (mean, across all concurrent requests)
Transfer rate:          3662.93 [Kbytes/sec] received
                        1518.91 kb/s sent
                        5181.84 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    7  20.0      4    1263
Processing:    85 1042 189.2   1075    1939
Waiting:       85 1041 189.2   1074    1938
Total:        119 1049 186.4   1079    2357

Percentage of the requests served within a certain time (ms)
  50%   1079
  66%   1087
  75%   1093
  80%   1097
  90%   1103
  95%   1114
  98%   1474
  99%   1739
 100%   2357 (longest request)

并发1000压测数据:

Concurrency Level:      1000
Time taken for tests:   11.349 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    440.57 [#/sec] (mean)
Time per request:       2269.801 [ms] (mean)
Time per request:       2.270 [ms] (mean, across all concurrent requests)
Transfer rate:          3572.29 [Kbytes/sec] received
                        1481.32 kb/s sent
                        5053.62 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   33 152.9      4    1251
Processing:    28 2001 731.2   2130    4551
Waiting:       27 1998 733.0   2129    4474
Total:         36 2034 726.9   2136    4574

Percentage of the requests served within a certain time (ms)
  50%   2136
  66%   2158
  75%   2170
  80%   2186
  90%   2490
  95%   3405
  98%   4067
  99%   4290
 100%   4574 (longest request)

4个geworker压测

配置

worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;

并发500压测数据:

Concurrency Level:      500
Time taken for tests:   11.628 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    429.98 [#/sec] (mean)
Time per request:       1162.847 [ms] (mean)
Time per request:       2.326 [ms] (mean, across all concurrent requests)
Transfer rate:          3486.44 [Kbytes/sec] received
                        1445.72 kb/s sent
                        4932.16 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2   10  18.9      4     116
Processing:   116 1094 167.1   1127    1393
Waiting:      116 1093 168.7   1127    1393
Total:        144 1104 157.4   1132    1396

Percentage of the requests served within a certain time (ms)
  50%   1132
  66%   1143
  75%   1155
  80%   1171
  90%   1194
  95%   1203
  98%   1213
  99%   1224
 100%   1396 (longest request)

并发1000压测数据:

Concurrency Level:      1000
Time taken for tests:   11.713 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    426.89 [#/sec] (mean)
Time per request:       2342.522 [ms] (mean)
Time per request:       2.343 [ms] (mean, across all concurrent requests)
Transfer rate:          3461.40 [Kbytes/sec] received
                        1435.34 kb/s sent
                        4896.73 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2  107 322.0      4    1605
Processing:   116 2011 465.7   2204    2448
Waiting:      116 2010 466.1   2204    2447
Total:        191 2118 523.7   2215    3790

Percentage of the requests served within a certain time (ms)
  50%   2215
  66%   2243
  75%   2322
  80%   2350
  90%   2384
  95%   2960
  98%   3290
  99%   3389
 100%   3790 (longest request)

8个worker压测数据

配置

worker_processes  8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

并发500压测数据:

Concurrency Level:      500
Time taken for tests:   12.393 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    403.46 [#/sec] (mean)
Time per request:       1239.294 [ms] (mean)
Time per request:       2.479 [ms] (mean, across all concurrent requests)
Transfer rate:          3271.38 [Kbytes/sec] received
                        1356.54 kb/s sent
                        4627.92 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    8  19.3      4    1185
Processing:    89 1160 1070.7    997    7552
Waiting:       89 1159 1070.7    996    7552
Total:        120 1168 1074.4   1006    7566

Percentage of the requests served within a certain time (ms)
  50%   1006
  66%   1100
  75%   1128
  80%   1155
  90%   1820
  95%   2921
  98%   5768
  99%   6677
 100%   7566 (longest request)

并发1000压测数据:

Concurrency Level:      1000
Time taken for tests:   12.456 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      41515000 bytes
Total body sent:        17215000
HTML transferred:       40685000 bytes
Requests per second:    401.42 [#/sec] (mean)
Time per request:       2491.160 [ms] (mean)
Time per request:       2.491 [ms] (mean, across all concurrent requests)
Transfer rate:          3254.87 [Kbytes/sec] received
                        1349.69 kb/s sent
                        4604.56 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5  184 465.6     39    3386
Processing:   269 2090 666.3   2215    7690
Waiting:      268 2059 689.5   2209    7690
Total:        322 2274 713.7   2277    8945

Percentage of the requests served within a certain time (ms)
  50%   2277
  66%   2335
  75%   2858
  80%   3038
  90%   3139
  95%   3184
  98%   3340
  99%   4088
 100%   8945 (longest request)

从压测数据来看,对双核的机器来说worker进程设置为2最合适,设置多个worker由于进程资源抢占导致性能下降。

<think>嗯,用户问的是关于Nginx的multi_accept配置,我需要先回想一下这个指令的作用和用法。记得在Nginx中,multi_accept是和事件模块相关的,特别是使用epoll、kqueue这样的I/O多路复用方法时才会生效的。 首先,multi_accept默认是关闭的,也就是off状态。它的作用是控制worker进程是否一次尽可能多地接受新的连接。如果开启的话,worker进程会在接收到新连接事件时,一次性处理所有当前准备好的连接,而不是一个一个来。这可能会在高并发场景下提升性能,但也要注意资源消耗的问题。 不过,我得确认一下这个指令的具体适用环境。比如,对于不同的操作系统和事件模型,multi_accept的表现是否一致。比如在Linux下使用epoll,或者FreeBSD下使用kqueue,这个指令是否有不同的影响。可能需要查一下Nginx的官方文档来确认。 另外,用户可能需要知道如何配置这个指令。通常是在events块里面设置,比如: ``` events { multi_accept on; worker_connections 1024; } ``` 这样开启multi_accept,并设置每个worker的最大连接数。不过要注意,worker_connections的数值需要根据实际情况调整,避免过多的连接导致资源不足。 然后需要解释开启和关闭multi_accept的区别。开启后,worker进程能更快地处理大量连接请求,减少事件循环的次数,但可能会增加单个worker的负载,如果处理不过来,反而会影响性能。关闭时,worker每次只处理一个新连接,可能更稳定,但在高并发时可能效率不够。 还要提到适用场景。比如,当服务器面临突发的高并发连接时,开启multi_accept可能更有效;而如果连接请求比较平稳,或者服务器资源有限,保持默认的off可能更安全。同时,需要结合其他配置参数,如worker_processesworker_connections等,综合调整才能达到最佳效果。 可能用户会有疑问,开启multi_accept是否会导致某些连接被延迟处理,或者是否会影响负载均衡的效果。这时候需要解释,虽然worker会一次性接受多个连接,但Nginx的事件处理机制仍然会公平地分配资源,不过在高负载下,确实需要监控系统资源,避免单个worker过载。 最后,要提醒用户在实际应用中进行试,通过工具如ab、wrk来比较开启前后的性能差异,根据具体结果调整配置。同时,参考Nginx的官方文档和社区的最佳实践,确保配置的合理性和稳定性。</think>在Nginx中,`multi_accept` 是一个与事件处理模型相关的配置指令,主要用于控制worker进程是否一次性接受所有新连接请求。以下为详细说明: --- ### 1. **作用与原理** - **功能定位**: -Nginx使用`epoll`(Linux)、`kqueue`(FreeBSD)等高效I/O多路复用模型时,`multi_accept`会生效。 - 它决定worker进程是否**批量接受**新的连接请求。 - **默认行为**: - 默认值为`off`,即worker进程每次事件循环**仅接受一个新连接**。 - 若设为`on`,worker进程会**尽可能多地接受所有就绪的新连接**。 --- ### 2. **配置语法** 在`nginx.conf`的`events`块中设置: ```nginx events { multi_accept on; # 开启批量接受 worker_connections 1024; # 需配合调整每个worker的最大连接数 } ``` --- ### 3. **开启与关闭的差异** | 场景 | 开启 (`multi_accept on`) | 关闭 (`multi_accept off`) | |-------------------|--------------------------------|--------------------------------| | **高并发处理** | 减少事件触发次数,提升吞吐量 | 逐个处理,可能增加延迟 | | **资源占用** | 单次负载较高,可能瞬时消耗更多CPU/内存 | 资源分配更平缓,稳定性更高 | | **适用性** | 突发流量或短连接密集型场景 | 平稳流量或长连接场景 | --- ### 4. **注意事项** - **性能权衡**: - 开启后可能提高吞吐量,但需确保服务器资源(CPU、内存)充足。 -worker进程处理速度跟不上新连接到达速度,可能导致请求堆积。 - **与`worker_connections`配合**: - `worker_connections`定义了单个worker的最大连接数。 - 当`multi_accept on`时,需合理设置此值,避免单个worker过载。 - **操作系统兼容性**: - 仅在支持`epoll`/`kqueue`的系统生效,对`select`或`poll`模型无效。 --- ### 5. **实际应用建议** - **试验证**: 使用工具(如`wrk`、`ab`)对比开启前后的QPS和延迟。 ```bash wrk -t4 -c1000 -d30s http://your_server/ ``` - **监控指标**: - 观察CPU使用率、内存占用及`active connections`变化。 - 通过Nginx状态模块(如`ngx_http_stub_status_module`)监控实时连接数。 --- ### 6. **示例场景** 假设某电商网站在大促期间遭遇瞬时流量高峰: 1. 开启`multi_accept on`,使worker快速接受大量新连接。 2. 结合负载均衡与连接池管理,确保后端服务不阻塞。 3. 调整`worker_processes`为CPU核心数,最大化利用多核资源。 --- ### 总结 `multi_accept`是一个需根据实际业务场景灵活调整的优化参数。在高并发场景下,合理开启可提升吞吐量,但需结合系统监控与试进行调优。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值