nginx 服务器并发优化

Posted 2020-10-27 一剑侵心

apache 提供的 ab 可以对服务器进行压力测试，

安装 ab：   apt-get install apache2-utils 

安装完后，ab 在目录  /usr/bin/ 下的。

执行： ab -c 并发数 -n 请求数 请求的URL    如：

       ab -c 2000 -n 50000 http://192.168.137.47/    表示对 http://192.168.137.47/ 进行50000次请求，并发数为 2000

我运行的机器不是在 192.168.137.47 上，运行时报了一个错误：  socket: Too many open files

运行：  ulimit -n  出现结果 1024，说明最大允许打开的文件描述符的数量为 1024，我们上面并发数为 2000，比1024大，运行下面的命令，设置一个较大的值：

       ulimit -n 20000

先运行小一点的压力测试参数，看看正确返回时， ab 给出的测试报告。如： ab -c 200 -n 5000 http://192.168.137.47/

Server Software:        Tengine/2.2.2   # 我用的是 Tengine （https://tengine.taobao.org/ 淘宝对 nginx 的扩展）
Server Hostname:        192.168.137.47
Server Port:            80

Document Path:          /
Document Length:        179 bytes

Concurrency Level:      200         # 命令中 -c 的值
Time taken for tests:   16.161 seconds    # 总共花费的时间
Complete requests:      5000      # 命令中 -n 的值
Failed requests:        0   #失败的请求数
Total transferred:      2110000 bytes    # 总共传输的数据量
html transferred:       895000 bytes   # 总共的 HTML 内容的传输量
Requests per second:    309.38 [#/sec] (mean)  # 吞吐率（平均值）
Time per request:       646.447 [ms] (mean)   # 平均一次请求所花费的时间，即用户的等待时间
Time per request:       3.232 [ms] (mean, across all concurrent requests)   # 服务器平均一次请求处理时间，吞吐率的倒数
Transfer rate:          127.50 [Kbytes/sec] received   # 平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
                      min  mean[+/-sd]  median   max
Connect:        0     20 111.8       1            1002
Processing:    4    595 596.6     455         3669
Waiting:         1     593 595.9     452         3608
Total:            4     616 604.5      483         3670

Percentage of the requests served within a certain time (ms)
  50%    483    # 50% 的用户等待时间不超过 483 ms
  66%    778    # 66% 的用户等待时间不超过 778 ms
  75%   1021
  80%   1119
  90%   1484
  95%   1804
  98%   2137
  99%   2337
 100%   3670 (longest request)

 

当加大参数时，如  ab -c 2000 -n 50000 http://192.168.137.47/

 这时出现了：   apr_socket_recv: Connection reset by peer (104)   这个错误（在命令里加上 -r 参数后，就不会报这个错了，而是会一直测试下去，直到达到 -n 设置的请求的数量），网上有人说是 ab 安装的问题，也可能是 ab 这个作为请求的客户端撑不住了。在高并发的情况下，如果服务器撑不住了，应该是服务器端报错，体现在ab测试完的报告里。因为我用的是虚拟机，一台真实电脑上，开了4台虚拟机（两台 tomcat 运行 web 服务，一台 nginx 服务器作负载均衡，一台运行压力测试的命令）。需要对 ab 客户机做一些优化（下面中的第3，4，5，8点）。下面是对 nginx 服务器进行优化：

 

高并发优化思路：

 

1. keepalive_timeout 默认值是 65，我改成 0 后，ab 端反而很快就报 apr_socket_recv: Connection reset by peer (104) 这个错误了，值为 65 时，报这个错误的时间会较晚，不知道是不是我其实只有一台真实机器的原因。

2.  增大 nginx 配置文件中的 worker_connections 数量

3. echo 50000 > /proc/sys/net/core/somaxconn  # 最大连接数

4. echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle  # 加快 tcp 连接的回收

5. echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse   # 空的 tcp 允许回收

6. echo 0 > /proc/sys/net/ipv4/tcp_syncookies  # 不做洪水抵御

7. 增大 nginx 配置文件中的 worker_rlimit_nofile 的值，比如： 10000

8. ulimit -n 20000

注：上面的一些设置，可以通过修改配置文件（/etc/sysctl.conf）达到：

net.ipv4.tcp_syncookies = 0  

#此参数是为了防止洪水攻击的，但对于大并发系统，要禁用此设置

 

net.ipv4.tcp_max_syn_backlog

#参数决定了SYN_RECV状态队列的数量，一般默认值为512或者1024，即超过这个数量，系统将不再接受新的TCP连接请求，一定程度上可以防止系统资源耗尽。可根据情况增加该值以接受更多的连接请求。

 

net.ipv4.tcp_tw_recycle

#参数决定是否加速TIME_WAIT的sockets的回收，默认为0。

 

net.ipv4.tcp_tw_reuse

#参数决定是否可将TIME_WAIT状态的sockets用于新的TCP连接，默认为0。

 

net.ipv4.tcp_max_tw_buckets

#参数决定TIME_WAIT状态的sockets总数量，可根据连接数和系统资源需要进行设置。

 

再次运行   ab -c 2000 -n 50000 http://192.168.137.47/， 发现能正常返回报告了，因为是单台机器上装的虚拟机，当并发达到一定数量时，不管怎么调，最后总会出错。