【运维知识进阶篇】集群架构-Nginx性能优化（一）

2023-08-10 232

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 【运维知识进阶篇】集群架构-Nginx性能优化

Nginx花了好多篇文章介绍了，今天谈谈它的优化。我们从优化考虑的方面，压力测试工具ab，具体的优化点三个方面去介绍，话不多说，直接开始！

优化考虑方面

1、了解系统结构、系统层次结构和瓶颈，结构方面，了解每个服务最大支持多少并发，支持多少的qps（每秒查询率）；系统层次结构方面，我们要考虑Nginx是做代理、动静分离、还是直接服务用户；瓶颈方面，可以通过top查看系统的CPU负载、内存使用率、总的运行进程，也可以通过日志分析请求情况。也可以通过压力测试工具，业务低谷期进行压力测试，了解这套系统能承担多少的请求和并发。

2、了解业务模式，我们的性能优化是为业务提供服务的，我们要了解业务类型，例如抢购类的业务，平时没什么流量，到了抢购时间流量就会激增。

3、还需要考虑性能和安全，不能只注重一点忽略了另一点，例如我们在设计防火墙功能时候，如果检测的过于严密，就会给性能带来影响，如果对性能完全追求，不顾服务的安全，也容易造成安全隐患，所以我们需要权衡好对应的点

我们可以从OSI模型去考虑优化方向

硬件：代理（CPU）、静态（磁盘IO）、动态（cpu、内存）

网络：带宽、丢包、延迟

系统：文件描述符（文件句柄数）

应用：服务与服务保持长连接http1.1

服务：静态资源服务优化

压力测试工具

在业务量没有增长之前，我们要做好响应准备，以防患业务量突增带来的接口压力，所以对于接口压力测试就显得非常重要，我们可以用测试工具，检测当前系统情况，看是否能满足对应压力的需求。

1、安装ab压力测试工具

[root@Web01 ~]# yum install -y httpd-tools

2、压力工具使用方式

-n 要执行的请求数

-c 请求的并发数

-k 是否开启长连接

[root@Web01 ~]# ab -n 200 -c 2 http://blog.koten.com/

3、配置Nginx静态网站与tomcat动态网站环境

1. #静态网站配置
2. [root@Web02 ~]# cat /etc/nginx/conf.d/test.conf 
3. server {
4.     listen 80;
5.     server_name test.koten.com;
6. 
7. location / {
8.     root /code;
9.     try_files $uri $uri/ @java;
10. index index.jsp index.html;
11.     }
12. 
13. location @java {
14.     proxy_pass http://172.16.1.8:8080;
15.     }
16. }
17. [root@Web02 ~]# nginx -t
18. nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
19. nginx: configuration file /etc/nginx/nginx.conf test is successful
20. [root@Web02 ~]# systemctl restart nginx
21. [root@Web02 ~]# echo 'nginx ab' > /code/ab.html
22. 
23. #动态网站配置
24. [root@Web02 ~]# wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.73/bin/apache-tomcat-9.0.73.tar.gz --no-check-certificate
25. [root@Web02 ~]# tar xf apache-tomcat-9.0.73.tar.gz
26. [root@Web02 ~]# cd /usr/share/tomcat/webapps/ROOT
27. [root@Web02 ROOT]# echo "test_tomcat" > tomcat.html
28. 
29. #静态资源压力测试
30. [root@Web01 ~]# ab -n 10000 -c 200 http://test.koten.com/ab.html
31. This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
32. Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
33. Licensed to The Apache Software Foundation, http://www.apache.org/
34. 
35. Benchmarking test.koten.com (be patient)
36. Completed 1000 requests
37. Completed 2000 requests
38. Completed 3000 requests
39. Completed 4000 requests
40. Completed 5000 requests
41. Completed 6000 requests
42. Completed 7000 requests
43. Completed 8000 requests
44. Completed 9000 requests
45. Completed 10000 requests
46. Finished 10000 requests
47. 
48. 
49. Server Software:        nginx/1.22.1
50. Server Hostname:        test.koten.com
51. Server Port:            80
52. 
53. Document Path:          /ab.html
54. Document Length:        9 bytes
55. 
56. Concurrency Level:      200
57. Time taken for tests:   3.536 seconds
58. Complete requests:      10000
59. Failed requests:        0
60. Write errors:           0
61. Total transferred:      2380000 bytes
62. HTML transferred:       90000 bytes
63. Requests per second:    2827.96 [#/sec] (mean)
64. Time per request:       70.722 [ms] (mean)
65. Time per request:       0.354 [ms] (mean, across all concurrent requests)
66. Transfer rate:          657.28 [Kbytes/sec] received
67. 
68. Connection Times (ms)
69.               min  mean[+/-sd] median   max
70. Connect:        0   18 130.3      0    3009
71. Processing:    12   48  41.2     45    1648
72. Waiting:        1   48  41.2     45    1648
73. Total:         31   66 148.7     45    3052
74. 
75. Percentage of the requests served within a certain time (ms)
76. 50%     45
77. 66%     46
78. 75%     46
79. 80%     47
80. 90%     50
81. 95%     56
82. 98%    245
83. 99%   1051
84. 100%   3052 (longest request)
85. 
86. #动态资源压力测试
87. [root@Web01 ~]# ab -n 10000 -c 200 http://test.koten.com/tomcat.html
88. This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
89. Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
90. Licensed to The Apache Software Foundation, http://www.apache.org/
91. 
92. Benchmarking test.koten.com (be patient)
93. Completed 1000 requests
94. Completed 2000 requests
95. Completed 3000 requests
96. Completed 4000 requests
97. Completed 5000 requests
98. Completed 6000 requests
99. Completed 7000 requests
100. Completed 8000 requests
101. Completed 9000 requests
102. Completed 10000 requests
103. Finished 10000 requests
104. 
105. 
106. Server Software:        nginx/1.22.1    #版本号
107. Server Hostname:        test.koten.com  #URL主机名
108. Server Port:            80              #请求端口
109. 
110. Document Path:          /tomcat.html    #请求路径
111. Document Length:        12 bytes        #HTTP相应数据的正文长度
112. 
113. Concurrency Level:      200             #并发用户数，是我们设置的参数
114. Time taken for tests:   12.337 seconds  #所有请求被处理完成所花费的时间
115. Complete requests:      10000           #总请求数量，我们设置的参数
116. Failed requests:        0               #失败的请求数量
117. Write errors:           0
118. Total transferred:      2500000 bytes   #所有请求的相应数据长度总和，包括每个HTTP响应数据的头部信息和正文数据的长度
119. HTML transferred:       120000 bytes    #所有请求的响应数据中正文数据的总和
120. Requests per second:    810.59 [#/sec] (mean)    #吞吐量，计算公式是总请求数除以处理完成这些请求数所花费的时间
121. Time per request:       246.733 [ms] (mean)    #用户平均请求等待时间，计算公式是处理完成所有请求数所花费的时间除以（总请求数除以并发用户数）
122. Time per request:       1.234 [ms] (mean, across all concurrent requests)        #服务器平均请求等待时间，计算公式是吞吐率的倒数，也可以通过用户平均请求等待时间除以并发用户数
123. Transfer rate:          197.90 [Kbytes/sec] received    #表示这些请求在单位时间内从服务器获取的数据长度，计算公式是所有请求的相应数据长度总和除以所有请求被处理完成所花费的时间，这个统计可以很好说明服务器的处理能力达到极限时，其出口宽带的需求量
124. 
125. Connection Times (ms)
126.               min  mean[+/-sd] median   max
127. Connect:        0    9  86.5      1    1007
128. Processing:    32  225 400.9    103    3555
129. Waiting:       32  225 400.8    103    3555
130. Total:         33  234 413.7    104    3567
131. 
132. Percentage of the requests served within a certain time (ms)
133. 50%    104
134. 66%    132
135. 75%    161
136. 80%    191
137. 90%    317
138. 95%   1100
139. 98%   1317
140. 99%   2083
141. 100%   3567 (longest request)

性能优化

一、影响性能的指标

1、网络

1）网络的流量；2）网络是否丢包；3）这些会影响http的请求与调用

2、系统

1）硬件有没有磁盘损坏，磁盘速率是否稳定；2）系统的负载、内存、系统稳定性

3、服务

1）连接优化，请求优化；2）根据业务形态做对应的服务设置

4、程序

1）接口性能；2）处理速度；3）程序执行效率

5、数据库

每个服务之间都或多或少有一些关联，我们需要将整个架构分层去看，找到对应系统或服务的短板，然后进行优化

二、系统性能优化

1、更改文件句柄

Linux一切皆文件，而文件句柄是文件的索引，文件句柄随着我们的进程调用频繁增加，系统默认的文件句柄有限制，不能让一个进程无限调用

1. [root@Web01 ~]# vim /etc/security/limits.conf    #文件句柄限制配置文件
2. 
3. 1、系统全局性修改。
4. # * 代表所有用户
5. * soft nofile 25535
6. * hard nofile 25535
7. 
8. 2.用户局部性修改
9. #针对root用户，soft仅提醒，hard限制，nofile打开最大文件数
10. root soft nofile 65535
11. root hard nofile 65535
12. 
13. 3.进程局部性修改
14. #针对nginx进程，nginx自带配置
15. worker_rlimit_nofile 30000

2、Time_wait状态重用

通过调整内核参数，让time_wait状态重用（端口重用）

1. [root@web01 ROOT]# vim /etc/sysctl.conf
2. net.ipv4.tcp_tw_reuse = 1     # 开启端口复用
3. net.ipv4.tcp_timestamps = 0   # 禁用时间戳
4. [root@web01 ROOT]# sysctl -p    #可以查看我们添加的内核参数
5. [root@web01 ROOT]# sysctl -a    #可以查看所有内核参数

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。

高并发短连接有两方面需要注意：

1、高并发可以让服务器短时间内占用大量端口，端口范围0-65535除去系统和其他服务并不多

2、在这个场景中，短连接表示业务处理+传输数据的时间远远小于TIMEWAIT超时的时间的连接

这个情况下，有可能http短连接话一秒处理数据，却要花几分钟停留在TIMEWAIT状态，而这几分钟一直占用着端口不工作，所以导致了资源浪费，在实际业务中，一般长连接对应的业务的并发量不会很高。

三、代理服务优化

1、长连接优化

Nginx作为代理服务，负责转发用户请求，在转发过程中建议开启HTTP长连接，用于减少握手次数，降低服务器损耗。

1. upstream http_backend {
2.     server 127.0.0.1:8080;
3.     keepalive 16;   #长连接
4. }
5. 
6. server {
7.     ...
8. location /http/ {
9.         proxy_pass http://http_backend;
10.         proxy_http_version 1.1;         #对于http协议应该指定为1.1
11.         proxy_set_header Connection ""; #清除“connection”头字段
12.         proxy_next_upstream error timeout http_500 http_502 http_503 http_504;  #平滑过渡
13.         proxy_set_header Host $http_host;
14.         proxy_set_header X-Real-IP $remote_addr;
15.         proxy_set_header X-Forwared-For $proxy_add_x_forwarded_for;
16.         proxy_connect_timeout 30s;      # 代理连接web超时时间
17.         proxy_read_timeout 60s;         # 代理等待web响应超时时间
18.         proxy_send_timeout 60s;         # web回传数据至代理超时时间
19.         proxy_buffering on;             # 开启代理缓冲区,web回传数据至缓冲区,代理边收边传返回给客户端
20.         proxy_buffer_size 32k;          # 代理接收web响应的头信息的缓冲区大小
21.         proxy_buffers 4 128k;           # 缓冲代理接收单个长连接内包含的web响应的数量和大小
22.     ...
23.     }
24. }

fastcgi服务器需要设置fastcgi_keep_conn以便保持长连接

1. upstream fastcgi_backend {
2.     server 127.0.0.1:9000;
3.     keepalive 8;
4. }
5. 
6. server {
7.     ...
8. location /fastcgi/ {
9.         fastcgi_pass fastcgi_backend;
10.         fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
11.         fastcgi_keep_conn on;   
12.         fastcgi_connect_timeout 60s;
13.         include fastcgi_params;
14.         ...
15.     }
16. }

注意：scgi和uwsgi协议没有保持连接的概念，但proxy、fastcgi、uwsgi协议都有cache缓存的功能，开启后可加速网站访问的效率。

2、keepalive最大连接数

设置通过keepalive连接提供的最大请求数，在发出最大请求数后，将关闭连接

1. Syntax: keepalive_requests number;
2. Default: keepalive_requests 100;
3. Context: upstream
4. 
5. #该指令出现在1.15.3版中

3、keepalive_timeout超时

保持的连接被自动关闭之前的时间限制（以秒为单位）

1. Syntax: keepalive_timeout timeout;
2. Default: keepalive_timeout 60s;
3. Context: upstream
4. 
5. #该指令出现在1.15.3版中

【运维知识进阶篇】集群架构-Nginx性能优化（一）

优化考虑方面

压力测试工具

性能优化

一、影响性能的指标

二、系统性能优化

1、更改文件句柄

2、Time_wait状态重用

三、代理服务优化

1、长连接优化

2、keepalive最大连接数

3、keepalive_timeout超时

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

【运维知识进阶篇】集群架构-Nginx性能优化 （一）

优化考虑方面

压力测试工具

性能优化

一、影响性能的指标

二、系统性能优化

1、更改文件句柄

2、Time_wait状态重用

三、代理服务优化

1、长连接优化

2、keepalive最大连接数

3、keepalive_timeout超时

热门文章

最新文章

相关课程

相关电子书

相关实验场景

【运维知识进阶篇】集群架构-Nginx性能优化（一）