Nginx优化秘籍

发表于： 2020年4月9日 2020年4月9日
分类： Nginx, 运维

Nginx调优

nginx并发数
nginx进程优化
nginx压缩
nginx本地缓存

1、nginx并发数设置

worker_processes 1;

这是用来配置nginx启动几个工作进程的，默认为1。而nginx还支持一个名为worker_cpu_affinity的配置项，也就是说，nginx可以为每个工作进程绑定CPU。我做了如下配置：

 events {
 worker_connections 1024;
}

2、nginx将进程绑定在固定核

worker_cpu_affinity 0010 0100 1000;

worker_processes 3;
worker_cpu_affinity 0010 0100 1000;
#这里0010 0100 1000是掩码，分别代表第2、3、4颗cpu核心。

重启nginx后，3个工作进程就可以各自用各自的CPU了。

ps -eo psr,pid,arg 查看

nginx的并发=worker_processes*worker_connections

3、nginx 压缩功能

压缩功能对于WEB服务器来说太重要了，主要体现在以下两个方向：

1）提升用户体验：传输数据变小，用户等待时间变短。

2）节省公司带宽成本：压缩后传输，传输数据变小，带宽占用的更少。

既然能给用户好的体验，又能给公司省钱。这么好的事情何乐不为呢，所以这个是工作中必备配置神器。

但是配置压缩需要更大家说一下注意事项：

1）图片、音视频不要压缩

2）小于1K的不要压缩，否则越压越大

3）压缩级别越大，就越消耗CPU

未开启压缩

开启压缩

代码如下：

gzip on; （启用 gzip 压缩功能）

gzip_http_version 1.1; 它的默认值是HTTP/1.1，就是说对HTTP/1.1协议的请求才会进行gzip压缩

gzip_disable "MSIE [1-6].";设置是禁用IE1-6版本的gzip压缩

gzip_proxied any; （nginx 做前端代理时启用该选项，表示无论后端服务器的headers头返回什么信息，都无条件启用压缩）

gzip_min_length 1024; （最小压缩的页面，如果页面过于小，可能会越压越大，这里规定大于1K的页面才启用压缩）

gzip_buffers 4 8k; （设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流 按照原始数据大小以8K为单位申请4倍内存空间）

gzip_comp_level 3; （压缩级别，1压缩比最小处理速度最快，9压缩比最大但处理最慢，同时也最消耗CPU,一般设置为3就可以了）

gzip_types text/plain text/css application/x-javascript application/javascript application/xml; （什么类型的页面或文档启用压缩）

开启压缩验证

4、nginx 本地缓存功能

浏览器缓存（Browser Caching）是为了加速浏览并节约网络资源，浏览器在用户磁盘上对最近请求过的文档进行存储。

客户端缓存和压缩有本质的区别，用户第一次下载数据后会被保存在客户本地硬盘，下次在使用的时候，只要本地资源没有过期，就直接从本地硬盘读取了，速度最快，因为不用去找服务器拿数据了。同样它优化了用户体验和节省了公司带宽成本

需要注意的是：

缓存一般缓存的是图片、网站框架、音视频等不常变化的数据。应用最好的就是百度首页，大家有没有发现有时候你没网都能打开百度首页啊，那就是看的你本地缓存。

nginx本地缓存配置指令

nginx可以通过 expires 指令来设置浏览器的Header

语法： expires [time|epoch|max|off]

默认值： expires off

作用域： http, server, location

使用本指令可以控制HTTP应答中的“Expires”和“Cache-Control”的头标，（起到控制页面缓存的作用）。
可以在time值中使用正数或负数。“Expires”头标的值将通过当前系统时间加上您设定的 time 值来获得。

epoch 指定“Expires”的值为 1 January, 1970, 00:00:01 GMT。
max 指定“Expires”的值为 31 December 2037 23:59:59 GMT，“Cache-Control”的值为10年。
-1 指定“Expires”的值为 服务器当前时间 -1s,即永远过期

缓存案例

图片缓存30天
location ~.*\.(jpg|png|jpeg)$
 {
 expires 30d;
 }

js css缓存一小时
location ~.*\.(js|css)?$
 {
 expires 1h;
 }

缓存验证

1.nginx优势说明 a. 占有内存少 b. 高并发能力强 (官方测试能够支撑5W并发连接，在实际生产环境中能到2-3W并发连接数) e. 支持Rewriter重写 (能够根据域名、URL的不同，将HTTP请求分到不同的后端服务器群组) f. 内置健康检查 (如果nginx后端有几个服务宕机了，不会影响前端访问，能自动检测服务状态) g. 节省带宽 (支持GZIP压缩，可以添加浏览器本地缓存的Header头) h. 稳定性高，反向代理，很少宕机 2.场景说明

测试数据：由于后端服务器采用集群部署，通过性能测试工具jmeter分析出后端服务端处理用户每秒请求数（QPS）的单并发峰值在8千左右。
问题分析途径：nginx日志。

1、通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息。 2、通过错误日志，你可以得到系统某个服务或server的性能瓶颈等

调优过程：实现nginx限流、安全配置、优化进程数及并发连接数、nginx状态监控等性能调优。
调优结果：当用户请求数达到此峰值时实现限流，保证有效的请求通过nginx转发给后端成功处理。ps:如果不做限流处理当请求数超过峰值时，有效的8千请求也会失效，造成服务器的宕机。

3. nginx日志切割实现

nginx日志默认没有分割，使用起来非常不方便

[root@bogon logs]# ll 
总用量 24 
-rw-r--r--. 1 root root 18431 6月   7 19:09 access.log 
-rw-r--r--. 1 root root   186 6月   6 19:39 error.log 
[root@bogon logs]# ll 
总用量 24 
-rw-r--r--. 1 root root 1853 6月   8 16:38 access.log 
-rw-r--r--. 1 root root   186 6月   6 17:39 error.log

解决方法-通过shell脚本实现日志切割

日志路径为：/data/nginx/logs目录下

shell脚本如下：

 #!/bin/bash 
#设置日志文件存放目录 LOG_HOME="/data/nginx/logs/" 
#备分文件名称 LOG_PATH_BAK="$(date -d yesterday +%Y%m%d%H%M)".access.log 
#重命名日志文件 
mv ${LOG_HOME}/access.log ${LOG_HOME}/${LOG_PATH_BAK}.log 
#向nginx主进程发信号重新打开日志 
kill -USR1 `cat /opt/nginx/logs/nginx.pid

创建crontab设置定时任务

*/1 * * * * sh /data/nginx/nginx_log.sh  
[root@bogon logs]# ll 
总用量 16 
-rw-r--r--. 1 root root 1238 6月   9 17:44 202002081743.access.log 
-rw-r--r--. 1 root root 2588 6月   9 17:45 202002081745.access.log 
-rw-r--r--. 1 root root    0 6月   9 17:46 access.log 
-rw-r--r--. 1 root root    0 6月   9 17:10 error.log

4.并发AB工具简介

相对性能测试工具jmeter而言，在Linux下ab工具更轻巧好用。BA命令简介：

key含义Document Path测试的页面Document Length页面的大小Concurrency Level并发数量、并发用户数Time taken for tests测试耗费总时间Complete requests请求总量、并发连接数Failed requests请求失败的数量Write errors错误数量Requests per second每秒钟的请求量、吞吐率Time per request每次请求需要时间、响应时间

Centos安装命令：

yum install httpd-tools –y

测试并发命令：

ab -c 1  -n 6  http://192.168.1.90:8070/index/index.html 
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 20 "-" "ApacheBench/2.3" "-" 
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 150 "-" "ApacheBench/2.3" "-" 
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 20 "-" "ApacheBench/2.3" "-" 
192.168.1.91 - - [09/Feb/2020:11:55:23 +0000] "GET /index/index.html HTTP/1.0" 200 150 "-" "ApacheBench/2.3" "-"

5. nginx限流有三种方式实现 • limit_conn_zone • limit_req_zone • ngx_http_upstream_module 前两种只能对客户端（即单一ip限流）

ngx_http_upstream_module限流示例(推荐) • 该模块是提供了我们需要的后端限流功能的 • 该模块有一个参数：max_conns可以对服务端进行限流，版本要求：在nginx1.11.5版本以后，配置参数：

upstream localhost{ 
server 192.168.1.90:8071  max_conns=5; 
server 192.168.1.90:8072 max_conns=5;
 }

执行结果【可以看到结果有一个已经错误了，同理可以限制服务端访问流量】：

[root@bogon ~]# ab -c 1  -n 6  http://192.168.1.90:8070/index/index.html 
This is ApacheBench, Version 2.3 <$Revision: 1430300 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/  
Benchmarking 192.168.1.90 (be patient).....done   
Server Software:        nginx/1.17.8 
Server Hostname:        192.168.1.90 
Server Port:            8070  
Document Path:          /index/index.html 
Document Length:        150 bytes  
Concurrency Level:      1 
Time taken for tests:   0.041 seconds 
Complete requests:      6 
Failed requests:        0  
Write errors:           1 
Total transferred:      2328 bytes 
HTML transferred:       900 bytes 
Requests per second:    146.03 [#/sec] (mean) 
Time per request:       6.848 [ms] (mean) 
Time per request:       6.848 [ms] (mean, across all concurrent requests) 
Transfer rate:          55.33 [Kbytes/sec] received

6. 高并发下Nginx安全配置

版本安全

Accept-Ranges: bytes 
Connection: keep-alive 
Content-Length: 20 
Content-Type: text/html 
Date: Sun, 09 Feb 2020 11:42:08 GMT 
ETag: W/"20-1581064798000" 
Last-Modified: Fri, 07 Feb 2020 08:39:58 GMT 
Server: nginx/1.17.8

响应头信息可以看到nginx的版本号，版本号暴露是不安全的，所以需要隐藏下nginx的版本号，配置server_tokens off;下面就看不到了。

http {     
server_tokens off;
 ... 
Accept-Ranges: bytes 
Connection: keep-alive 
Content-Length: 150 
Content-Type: text/html 
Date: Sun, 09 Feb 2020 11:45:09 GMT 
ETag: W/"150-1581063242000" 
Last-Modified: Fri, 07 Feb 2020 08:14:02 GMT 
Server: nginx

IP安全配置

白名单配置： 
location / { 
allow 192.168.136.1;
 deny all;
 } 
黑名单设置： 
location / { 
deny 192.168.136.1;
 allow all; }

文件安全配置

location /logs { 
autoindex on; 
root /opt/nginx/; 
} 
location ^/logs~*\.(log|txt)$ { 
add_header Content-Type text/plain; 
root /opt/nginx/;
 }

7. Nginx配置进程数、并发数、系统优化

调整Nginx的主配置文件,增加并发量

worker_processes 2; #调整到与CPU数量一致 
events { 
worker_connection 65535; #每个worker最大并发连接数
 }

调整内核参数

[root@proxy ~]# ulimit -a #查看所有的属性值 
[root@proxy ~]# ulimit -Hn 10000 #临时设置硬限制
[root@proxy ~]# ulimit -Sn 10000 #设置软限制 
[root@proxy ~]# vim /etc/security/limits.conf ... 
* soft nofile 100000 
* hard nofile 100000 
用户/组 软/硬限制 需要限制的项目 限制的值

验证

ab -n 1 -c 20000 http://192.168.1.131/

8.高并发下Nginx状态监控

配置Nginx的监控选项(配置文件路径：nginx.conf) 添加如下代码：

#设定Nginx状态访问地址
 location /NginxStatus {
 stub_status on; 
 access_log off; 
}

./configure --prefix=/opt/nginx/ --with-http_stub_status_module

参数说明：

活跃的连接数量 active connections 总共处理了n个连接 , 成功创建n次握手, 总共处理了n个请求 server accepts handled requests 每个连接有三种状态waiting、reading、writing reading —读取客户端的Header信息数.这个操作只是读取头部信息，读取完后马上进入writing状态，因此时间很短 writing — 响应数据到客户端的Header信息数.这个操作不仅读取头部，还要等待服务响应，因此时间比较长。 waiting — 开启keep-alive后等候下一次请求指令的驻留连接. 正常情况下waiting数量是比较多的，并不能说明性能差。反而如果reading+writing数量比较多说明服务并发有问题。查看Nginx并发进程数：ps -ef|grep nginx | wc -l 查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

解析：

CLOSED //无连接是活动的或正在进行 LISTEN //服务器在等待进入呼叫 SYN_RECV //一个连接请求已经到达，等待确认 SYN_SENT //应用已经开始，打开一个连接 ESTABLISHED //正常数据传输状态/当前并发连接数 FIN_WAIT1 //应用说它已经完成 FIN_WAIT2 //另一边已同意释放 ITMED_WAIT //等待所有分组死掉 CLOSING //两边同时尝试关闭 TIME_WAIT //另一边已初始化一个释放 LAST_ACK //等待所有分组死掉查看Web服务器TCP连接状态：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 最后并发超过峰值后的服务端jvm监控显示正常

tingyuxinsheng@gmail.com

1282

tingyuxinsheng@gmail.com

发表评论 取消回复

发表评论取消回复