本文详细介绍Nginx服务器的性能优化策略，包括工作进程、长连接、数据压缩、客户端缓存等方面的配置优化，旨在提升服务器并发处理能力，增强用户体验，有效节省资源。
一、Nginx优化思路
1、优化目的
标准情况下，软件默认的参数都是对安装软件的硬件标准（最低配置）来设置的，目前我们服务器的硬件资源远远大于要求的标准，所以为了让服务器性能更加出众，充分利用服务器的硬件资源，我们一般需要优化APP的并发数来提升服务器的性能。
总结来说：1.服务器大并发实现；2.提升用户体验；3.为公司省钱。
二、工作进程优化
1、优化方案
Nginx是主进程+工作进程模型，也就是一个主进程会挂几个工作进程。
- worker_processes 1; 该指令指定工作进程数量
一般按照CPU的总核心数调整，优化思想是：保证一个进程跑在一个核上，将每个核充分利用起来。如果CPU的压力依然很小，可以设置保证一个核两个进程。 - worker_cpu_affinity 0010 0100 1000; 该指令调整CPU的亲和力
要保证一个核心上一个进程，这需要设置CPU的亲和力，这里用二进制掩码来计算数字是几。 - worker_connections 1024; 一个工作进程的并发数
这里设置是一个工作进程可以处理多少个连接，也就是并发数设置。
2、方案验证
（1）首先查看确认当前server核心数
$ cat /proc/cpuinfo | grep "flags" | wc -l
4（2）并发优化，配置修改nginx.conf如下所示：
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000; # 依次代表从1到4这四个核
events {
worker_connections 10240; # 这个值一般先设比较小，观察进程消耗再决定是否增加并发数
}（3）nginx服务检查
# 查看进程及进程是否处于对应核心上
$ ps -eo psr,pid,args | grep "nginx"
0 13977 nginx: master process /usr/local/nginx/sbin/nginx # 父进程
0 13978 nginx: worker process
1 13979 nginx: worker process
2 13980 nginx: worker process
3 13981 nginx: worker process
0 14284 grep --color=auto nginx
# 查看nginx连接数
$ netstat -antpl | grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 13977/nginx: master
# 查看nginx当前连接的人数
$ netstat -antpl | grep nginx | grep ESTABLISHED | wc -l
0三、长连接
1、什么是长连接，为什么要使用长连接？
nginx这种web服务器软件都是属于TCP协议的软件，TCP协议的特点就在于每次连接时要进行三次握手，握手成功后再通讯数据，通讯结束后四次挥手断开连接。
而http协议是一个无状态协议， 每次进行通讯都要三次握手四次挥手，那服务器就需要经常去维护握手和断开。 服务器压力过大、浪费的资源也过多。
因此一般都需要开启长连接，在第一个请求结束后，等一段时间，如果这个时间内，再有请求过来，则不断开连接，直接将数据发送给客户端。这样就降低了握手和挥手的次数和频率。
2、长连接配置方法
# 关闭长连接：0代表关闭
keepalive_timeout 0;
# 开启长连接
# keepalive_timeout 65;
# 一个长连接处理最大请求数（定期释放内存，防止内存溢出）
# keepalive_requests 8192;3、长连接状态查看
（1）服务器上查看连接状态
关闭长连接时：
# 浏览器访问完立刻进入TIME_WAIT状态（主动关闭）
$ netstat -antpl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1317/master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14698/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1095/sshd
tcp 0 0 192.168.31.42:80 192.168.31.28:64977 TIME_WAIT -
tcp 0 0 192.168.31.42:80 192.168.31.28:64978 TIME_WAIT -
tcp 0 0 192.168.31.42:80 192.168.31.28:64979 TIME_WAIT -
tcp 0 0 192.168.31.42:22 192.168.31.28:64678 ESTABLISHED 14636/sshd: root@pt
tcp6 0 0 ::1:25 :::* LISTEN 1317/master
tcp6 0 0 :::22 :::* LISTEN 1095/sshd
# 一段时间后连接消息消失
$ netstat -antpl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1317/master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14698/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1095/sshd
tcp 0 0 192.168.31.42:22 192.168.31.28:64678 ESTABLISHED 14636/sshd: root@pt
tcp6 0 0 ::1:25 :::* LISTEN 1317/master
tcp6 0 0 :::22 :::* LISTEN 1095/sshd开启长连接时：
# 由于前面设置长连接超时时间是65秒，这段时间内一直保持在ESTABLISHED状态：
$ netstat -antpl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1317/master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14828/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1095/sshd
tcp 0 0 192.168.31.42:80 192.168.31.28:51700 ESTABLISHED 14829/nginx: worker
tcp 0 0 192.168.31.42:22 192.168.31.28:50373 ESTABLISHED 14777/sshd: root@pt
tcp 0 0 192.168.31.42:22 192.168.31.28:64678 ESTABLISHED 14636/sshd: root@pt
tcp 0 0 192.168.31.42:80 192.168.31.28:51701 ESTABLISHED 14829/nginx: worker
tcp6 0 0 ::1:25 :::* LISTEN 1317/master
tcp6 0 0 :::22 :::* LISTEN 1095/sshd
# 时间超时长连接断开
$ netstat -antpl
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1317/master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14828/nginx: master
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1095/sshd
tcp 0 0 192.168.31.42:22 192.168.31.28:50373 ESTABLISHED 14777/sshd: root@pt
tcp 0 0 192.168.31.42:22 192.168.31.28:64678 ESTABLISHED 14636/sshd: root@pt
tcp6 0 0 ::1:25 :::* LISTEN 1317/master
tcp6 0 0 :::22 :::* LISTEN 1095/sshd （2）浏览器上查看连接状态
关闭长连接时：
开启长连接时：
四、压缩优化（数据压缩）
gzip(GNU-ZIP)是一种压缩技术。经过gzip压缩后页面大小可以变为原来的30%甚至更小，这样，用户浏览页面的时候速度会块得多。gzip的压缩页面需要浏览器和服务器双方都支持，实际上就是服务器端压缩，传到浏览器后浏览器解压并解析。浏览器那里不需要我们担心，因为目前的巨大多数浏览器都支持解析gzip过的页面。
Nginx的压缩输出有一组gzip压缩指令来实现。相关指令位于http{….}两个大括号之间。
1、nginx配置gzip
gzip on; # 启动gzip压缩功能
gzip_proxied any; # nginx做前端代理时启用该选项，表示无论后端服务器的headers返回什么信息，都无条件启用压缩
gzip_min_length 1k; # 小于1k的小文件不压缩（小文件可能会越压缩越大）
gzip_buffers 4 8k; # 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流，按照原始数据大小以8k为单位申请4倍内存空间
gzip_comp_level 6; # gzip压缩级别，1压缩比最小处理速度最快，9压缩比最大处理最慢也最消耗CPU，一般设置为3即可
gzip_types text/plain text/css application/x-javascript application/javascript application/xml; # 什么类型的页面或文档启用压缩
gzip_vary on; # 开启在http header中添加Vary:Accept-Encoding2、字段详解
- gzip off（on）;
该指令用于开启或关闭gzip模块(on/off) - gzip_min_length 1k;
启用gzip压缩的最小文件，小于设置值的文件将不会压缩。页面字节数从header头得content-length中进行获取。默认值是0，不管页面多大都压缩。建议设置成大于1k的字节数，小于1k可能会越压越大。 - gzip_comp_level 1;
gzip 压缩级别，1-9，数字越大压缩的越好，也越占用CPU时间。因此会有传输快慢和CPU消耗大小平衡的问题。 - gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png application/vnd.ms-fontobject font/ttf font/opentype font/x-woff image/svg+xml;
进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。 - gzip_vary on;
是否在http header中添加Vary: Accept-Encoding，建议开启。给代理服务器用的，有的浏览器支持压缩，有的不支持，所以避免浪费不支持的也压缩，所以根据客户端的HTTP头来判断，是否需要压缩 - gzip_disable "MSIE [1-6].";
禁用IE 6 gzip - gzip_buffers 32 4k;
设置压缩所需要的缓冲区大小；32 4k代表以4k为单位，安装原始数据大小以4k为单位的32倍申请内存。 - gzip_http_version 1.0;
设置gzip压缩针对的HTTP协议版本（1.0 / 1.1）
五、客户端缓存优化
1、语法和配置方法
语法：expires [time|epoch|max|off]
默认值：expires off
作用域：http,server,location
location ~* \.(js|css)?$ {
expires 1h;
}2、实现示例
server {
listen 80;
server_name localhost;
location / {
root html/web1;
index index.html index.htm;
}
# 客户端缓存设置：png或gif文件在客户端缓存一个小时
location ~* \.(png|gif)$ {
expires 1h;
}测试浏览器刷新以Chrome为例：
- ctrl+f5
清空本地缓存从服务器拿数据 - F5或者 点击 浏览器的刷新图标
优先从本地找，然后去找服务器核对信息是否一致。一致则返回304，从本地拿数据 - 回车
从本地缓存拿数据
六、思考
公司网站日常PV 60万，Nginx服务器该如何优化？
扫一扫
474
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
