Nignx性能优化（十八）
文章目录
-
- 1. 性能优化概述
- 2. 压力测试工具
- 3. 系统性能优化
- 4. 代理服务优化
- 5. 静态资源优化
-
- 5.1 静态资源缓存
- 5.2 静态资源读取
- 5.3 静态资源压缩
- 5.4 防止资源倒链
- 5.5 允许跨域访问
- 5.6 CPU亲和配置
- 5.7 通用优化配置
- 6. PHP服务优化
- 7. 自我总结
1. 性能优化概述
优化前需要考虑的内容：
（1）系统结构和瓶颈
运行的什么业务，有哪些服务，每个服务支撑多大的并发。Nginx作为静态资源的服务并发是多少，支持多少的访问请求（ab压测），top命令查看资源的使用情况，使用stub_status模块查看当前的连接情况。
（2）了解业务模式
了解每个业务接口的类型，电商网站中的抢购模式，这种情况下面，平时没什么流量，但到了抢购时间流量会突增
（3）了解系统层次化的结构
我们使用nginx做的是代理、还是动静分离、还是后端直接服务用户,做好相应的梳理，以便更好的服务业务
（4）性能与安全
往往注重了性能，但是忽略了安全。往往过于注重安全，对性能又会产生影响。比如：我们在设计防火墙功能时，检测过于严密，这样就会给性能带来影响。
从OSI模型考虑优化方向：
（1）硬件： 代理(CPU) 静态(磁盘IO) 动态(cpu、内存)，程序需要做解析，需要调内存做解析
（2）网络：网络是否有丢包，是否有延迟，公有云把网络拉到最高
（3）系统：文件描述符(文件句柄)【云主机默认给我们调整过了】
（4）应用：服务与服务保持长连接 http1.1
（5） 服务：静态资源服务优化
小总结:
(1) 查看一个进程占用几个文件描述符
tail -f /etc/passwd（查看一个文件）
ctrl + z（挂起）
ps aux | grep tail （看一下是哪一个进程）
ll /etc/proc/30727/fd （查看一个文件占用了五个文件描述符，每个进程在读取文件的时候，都会占用文件
描述符，系统对文件描述符默认是1024，需要调整系统的文件描述符）
(2)一直保持长连接在某些业务的场景下可能变的不太适用
代理与web已经断开了，time-wait 但是web的端口还占用着，如果请求过多端口会被耗尽，没有办法接收更多的
请求了
2. 压力测试工具
安装ab压力测试工具
[root@web01 conf.d]# yum install httpd-tools -y
压测工具使用方式
[root@web01 ~]# ab -n 200 -c 2 http://127.0.0.1/
#-n 要执行的请求数
#-c 请求的并发数
#-k 是否开启长连接
举个栗子：nginx和tomcat比较
配置nginx：
[root@lb01 conf.d]# cat try.conf
server {
listen 80;
server_name try.oldboy.com;
location / {
root /code;
try_files $uri $uri/ @java;
index index.jsp index.html;
}
location @java {
proxy_pass http://172.16.1.8:8080;
}
}
配置nginx使用的静态页面
[root@lb01 conf.d]# echo "nginx ab" > /code/ab.html
配置tomcat使用的静态页面
[root@web02 ~]# wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-9/v9.0.16/bin/apache-tomcat-9.0.16.tar.gz
[root@web02 ~]# tar xf apache-tomcat-9.0.16.tar.gz
[root@web02 ~]# cd /usr/share/tomcat/webapps/ROOT
[root@web02 ROOT]# echo "oldboy_tomcat" > tomcat.html
进行ab测试nginx和tomcat对静态文件处理能力
#压测工具测试nginx处理静态资源
[root@lb01 conf.d]# ab -n 10000 -c 200 http://try.oldboy.com/ab.html
Requests per second: 9272.58 [#/sec] (mean)
# 压测工具测试tomcat处理静态资源
[root@lb01 conf.d]# ab -n 10000 -c 200 http://try.oldboy.com/tomcat.html
Time per request: 99.119 [ms] (mean)
小结论：
（1）nginx处理静态文件的能力比tomcat强
（2）tomcat一般解析jsp文件，而不是静态文件的处理，公司就算运行Java环境，一定会有nginx的，借助nginx
处理静态资源，由tomcat解析动态资源
了解影响性能指标
1、网络
（1）网络的流量
（2）网络是否丢包
（3）这些会影响http的请求与调用
2、系统
（1）硬件有没有磁盘损坏，磁盘速率
（2）系统的负载、内存、系统稳定性
3、服务
（1）连接优化。请求优化
（2）根据业务形态做对应的服务设置
4、程序
（1）接口性能
（2）处理速度
（3）程序执行效率
5、数据库
#每个服务与服务之间都或多或少有一些关联，我们需要将整个架构进行分层，找到对应系统或服务的短板，然后进行优化
3. 系统性能优化
文件句柄（文件描述符）：
Linux一切皆文件，文件句柄可以理解为就是一个索引，文件句柄会随着我们进程的调用频繁增加，系统默认文件句柄是有限制的，不能让一个进程无限的调用，所以我们需要限制每个 进程和每个服务使用多大的文件句柄，文件句柄也是必须要调整的优化参数。（文件句柄可以理解为inode的索引）
（1）文件句柄的设置方式：
[root@lb01 ~]# vim /etc/security/limits.conf
1、系统全局性修改。
# * 代表所有用户
* soft nofile 25535
* hard nofile 25535
2.用户局部性修改
#针对root用户，soft仅提醒，hard限制，nofile打开最大文件数
root soft nofile 65535
root hard nofile 65535
3.进程局部性修改
#针对nginx进程，nginx自带配置
worker_rlimit_nofile 30000
4.调整内核参数：让time_wait状态重用(端口重用)[flag]
[root@web01 ROOT]# vim /etc/sysctl.conf
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 0 # 特别要注意！！！
[root@web01 ROOT]# sysctl -p #可以查看我们添加的内核参数
[root@web01 ROOT]# sysctl -a #可以查看所有内核参数
（2）在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
（3）关注高并发短连接的原因
第一：高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了
第二：在这个场景中，短连接表示业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间的连接。
注意：取一个web页面,1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的，长连接业务的服务就不需要考虑TIMEWAIT状态，，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。
4. 代理服务优化
nginx作为代理服务，负责转发用户的请求，那么在转发的过程中建议开启HTTP长连接，用于减少握手次数，降低服务器损耗。
长连接语法示例：
Syntax: keepalive connection;
Default: -
Context: upstream
#该指令出现在1.1.4版中
配置nginx代理服务使用长连接方式
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16; #长连接
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1; #对于http协议应该指定为1.1
proxy_set_header Connection ""; #清除“connection”头字段
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; #平滑过渡
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwared-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30s; # 代理连接web超时时间
proxy_read_timeout 60s; # 代理等待web响应超时时间
proxy_send_timeout 60s; # web回传数据至代理超时时间
proxy_buffering on; # 开启代理缓冲区,web回传数据至缓冲区,代理边收边传返回给客户端
proxy_buffer_size 32k; # 代理接收web响应的头信息的缓冲区大小
proxy_buffers 4 128k; # 缓冲代理接收单个长连接内包含的web响应的数量和大小
...
}
}
对于fastcgi服务器，需要设置fastcgi_keep_conn以便保持长连接[flag]
upstream fastcgi_backend {
server 127.0.0.1:9000;
keepalive 8;
}
server {
...
location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_keep_conn on;
fastcgi_connect_timeout 60s;
include fastcgi_params;
...
}
}
小提示：
1.scgi和uwsgi协议没有保持连接的概念。
2.但无论是proxy、fastcgi、uwsgi协议都有cache缓存的功能，开启后可加速网站访问的效率。（取决硬件）
keepalive_requests设置通过一个keepalive连接提供的最大请求数，在发出最大请求数后，将关闭连接
Syntax: keepalive_requests number;
Default: keepalive_requests 100;
Context: upstream
#该指令出现在1.15.3版中
keepalive_timeout设置超时，再次期间与代理服务器的空闲keepalive连接将保持打开状态
Syntax: keepalive_timeout timeout;
Default: keepalive_timeout 60s;
Context: upstream
#该指令出现在1.15.3版中
5. 静态资源优化
5.1 静态资源缓存
Nginx作为静态资源Web服务器，用于静态资源处理，传输非常的高效
静态资源缓存：
浏览器缓存设置用于提高网站性能，尤其是新闻网站，图片一旦发布，改动的可能是非常小的，所以我们希望能否用户访问一次后，图片缓存在用户的浏览器长时间缓存。 浏览器是有自己的缓存机制，他是基于HTTP协议缓存机制来实现的，在HTTP协议中有很多头信息，那么实现浏览器的缓存就需要依赖特殊的头信息来与服务器进行特殊的验证，如Expires（http/1.0）；Cache-control（http/1.1）。
浏览器缓存过期校验机制：
说明：
1、浏览器请求服务器会先进行Expires、Cache-Control的检查，检查缓存是否过期，如果没有过期则直接从缓存文件中读取。
2、如果缓存过期首先检查是否存在etag，如果存在那么客户端会向web服务器请求If-None-Match，与etag值进行比对，有服务器决策返回200还是304。
3、如果etag不存在，则进行last-Modified检查，客户端会向web服务器请求if-Modified-Since，与last-Modified进行比对，有服务器决策返回200还是304。
Last-Modified：服务器上文件的最后修改时间
Etag：文件标识
Expires：本地缓存目录中，文件过期的时间（由服务器指定具体的时间）
Cache-control：本地缓存目录中，文件过期的时间（由服务器指定过期的间隔时间，由于浏览器根据间隔生成具体的时间）
自我总结：
1.现在设置缓存10s中的时间。10s到了 缓存是不是应该过期。
浏览器If-None-Match "9-1550193224000" 询问 web服务器 etag "9-1550193224000"
浏览器认为只是缓存过期，内容并没有修改，所以协商后还是304
浏览器If-Modified-Since Tue, 29 Jan 2019 02:29:51 GMT
询问
web服务器 Last-Modified: Tue, 29 Jan 2019 02:29:51 GMT
浏览器认为只是缓存过期，内容并没有修改，所以协商后还是304
ETag: "5c4fba9f-6" ETag: "5c662c2a-a"
If-None-Match: "5c4fba9f-6" If-None-Match: "5c4fba9f-6"
配置静态资源缓存expires
#作用：添加Cache-Control Expires头
Syntax: expires [modified] time;
epoch | max | off;
Default: expires off;
Context: http, server, location, if in location
配置静态资源缓存场景
server {
listen 80;
server_name static.oldboy.com;
location ~ .*\.(jpg|gif|png)$ {
expires 7d;
}
location ~ .*\.(js|css)$ {
expires 30d;
}
}
如果开发代码没有正式上线，希望静态文件不被缓存
#取消js、css、html等静态文件缓存
location ~ .*\.(js|css|html)$ {
add_header Cache-Control no-store;
add_header Pragma no-cache;
}
5.2 静态资源读取
文件读取高效sendfile，如下图
Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location
传统读取文件方式 VS sendfile读取文件方式
将多个包一次发送，用于提升网络传输效率，大文件推荐打开，需要开启sendfile才行
Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location
提高网络传输实时性，需要开启keepalive，来一个包发一个包不等待行
Syntax: tcp_nodelay on | off;
Default: tcpnodelay off;
Context: http, server, location
5.3 静态资源压缩
Nginx将响应报文发送至客户端之前启用压缩功能，然后进行传输，这能够有效地节约带宽，并提高响应至客户端的速度。
gzip传输压缩，传输前压缩，传输后解压
Syntax: gzip on | off;
Default: gzip off;
Context: http, server, location, if in location
gzip压缩哪些文件
Syntax: gzip_types mime-type ...;
Default: gzip_types text/html;
Context: http, server, location
gzip压缩比率，加快传输，但压缩本身比较耗费服务器性能
Syntax: gzip_comp_level level;
Default:gzip_comp_level level 1;
Context: http, server, location
gzip压缩协议版本，压缩使用在http哪个协议，主流选择1.1版本
Syntax: gzip_http_version 1.0 | 1.1;
Default:gzip_http_version 1.1;
Context: http, server, location
静态资源压缩
[root@Nginx conf.d]# cat static_server.conf
server {
listen 80;
server_name static.oldboy.com;
location ~* .*\.(jpg|gif|png)$ {
root /code/images;
gzip on;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_types image/jpeg image/gif image/png;
}
}
针对txt文件压缩
[root@Nginx conf.d]# cat static_server.conf
server {
listen 80;
server_name static.oldboy.com;
sendfile on;
location ~ .*\.(txt|xml|html|json|js|css)$ {
gzip on;
gzip_http_version 1.1;
gzip_comp_level 1;
gzip_types text/plain application/json application/x-javascript application/css application/xml text/javascript;
}
}
文本文件的压缩比图片文件压缩的效果好
5.4 防止资源倒链
防盗链，指的是防止资源被其他网站恶意盗用。
基础防盗链设置思路：主要是针对客户端请求过程中所携带的一些Header信息来验证请求的合法性，比如客户端在请求的过程中都会携带referer信息。优点是规则简单，配置和使用都很方便，缺点是防盗链所依赖的Referer验证信息是可以伪造的，所以通过referer信息防盗链并非100%可靠，但是他能够限制大部分的盗链情况。
Syntax: valid_referers none | blocked | server_name | string ...;
Default: -;
Context: server, location
#none: referer来源头部为空的情况
#blocked: referer来源头部不为空，这些都不以http://或者https://开头
#server_name: 来源头部信息包含当前域名，可以正则匹配
模拟盗链实例
（1）配置被盗链机器
10.0.0.8 static.oldboy.com
#1.配置Nginx
[root@web02 conf.d]# cat static.conf
server {
listen 80;
server_name static.oldboy.com;
root /code;
location / {
index index.html;
}
#添加防盗链：
location ~* \.(gif|jpg|png|bmp)$ {
valid_referers none blocked *.oldboy.com;
if ($invalid_referer) {
return 403; #可以选择直接返回403
rewrite ^(.*)$ /daolian.png break; #也可以选择返回一张水印的图片，给公司做广告
}
}
#2.上传2张图片
一张是可以被盗链的图片
一张是广告位的图片
#3.重启服务器
[root@web02 code]# systemctl restart nginx
以上配置含义表示，所有来自*.oldboy.com都可以访问到当前站点的图片，如果来源域名不在这个列表中，那么$invalid_referer等于1，在if语句中返回一个403个客户，这样用户便会看到一个403的页面
（2）另一台机器盗链
10.0.0.7 dl.oldboy.com ###盗链服务器
#1.配置Nginx
[root@web01 conf.d]# cat try.conf
server {
server_name dl.oldboy.com;
listen 80;
root /code;
location / {
index index.html;
}
}
#2.配置盗链的页面
[root@web01 code]# cat /code/tt.html
oldboyedu.com
#根据情况修改你的服务器地址
通过命令来修改来源的refer信息，破解防盗链
#伪造协议头访问
[root@web01 code]# curl -e "https://www.baidu.com" -I http://test.oldboy.com/Picture/daolian.jpg
HTTP/1.1 403 Forbidden
Server: nginx
Date: Thu, 10 Oct 2019 09:01:05 GMT
Content-Type: text/html; charset=utf-8,gbk
Content-Length: 162
Connection: keep-alive
#伪造协议头访问
[root@web01 code]# curl -e "https://www.oldboy.com" -I http://test.oldboy.com/Picture/daolian.jpg
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 10 Oct 2019 09:01:35 GMT
Content-Type: image/jpeg
Content-Length: 556417
Last-Modified: Thu, 10 Oct 2019 07:14:19 GMT
Connection: keep-alive
ETag: "5d9eda4b-87d81"
Accept-Ranges: bytes
希望某些网站可以盗链：
location ~ .*\.(jpg|png|gif) {
root /data;
valid_referers none blocked *.oldboy.com server_name ~\.google\. ~\.baidu\.;
if ( $invalid_referer ) {
return 403;
}
}
小提示：
可以在被盗服务器设置保存的日志，这样可以看谁访问我的盗取我的图片
在浏览器中访问倒链服务器，可以在被盗服务器中看到日志
5.5 允许跨域访问
浏览器访问a网站时，a网站会利用到ajax或其他方式，同时请求b网站，这样的话会出现请求一个页面，使用了2个域名，这种方式对浏览器来说默认是禁止。
这个是浏览器的功能跟Nginx有什么关系那？？？
浏览器阻止了，为什么有允许那？？？
在许多公司历史遗留的项目上面可能有这样的问题，比如a网站必须调到b网站里面的某些资源，如果拒绝掉了，就不能正常的访问。代码运行的很好，就不要改代码。
那Nginx语序跨站访问与浏览器有什么关系呢，因为浏览器会读取Access-Control-Allow-Origin的头信息，如果服务端允许，则浏览器不会进行拦截。
Syntax: add_header name value [always];
Default: -;
Context: http, server, location, if in location
小理解： 请求a.con的时候，需要通过某些技术调用b.com这个域名，b必须允许a.com这个域名过来,才能正常的请求。如果没有配置，默认是拒绝掉的。（需要用到真实的域名来演示实验，如果用虚拟机来演示实验，add_header Access-Control-Allow-Origin *，必须允许全部）
（1）准备a网站
#编辑nginx配置文件
[root@web02 code]# vim /etc/nginx/conf.d/s.conf
server {
listen 80;
server_name s.oldboy.com;
location / {
root /code;
index index.html;
}
}
#编辑html文件
[root@Nginx ~]# cat /code/tt.html
测试ajax和跨域访问
跨域访问测试
（2）准备b网站
server {
listen 80;
server_name web.oldboy.com;
root /code;
index index.html;
charset utf-8;
location ~ .*\.(html|htm)$ {
add_header Access-Control-Allow-Origin *; # 允许全部的域名访问，可以使用域名的方式。比如*.oldboy.com
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
}
}
（3）在浏览器访问测试
小提示：
在被动方添加主动方的域名，然后主动方可以正常的跨站
5.6 CPU亲和配置
理解：如果一颗cup有四个核心，前四个work在四个核心上，第五个work也会使用cpu0这个核心，这时就会发生抢占、轮询使用cpu，这是会有性能的消耗。所以Nginx提供了一个cpu亲和，就是把把每一个work进程绑定到固定的核心上面去（解决完当前的work进程，在解决其他的work进程），官方建议，work进程数与cpu核心数一致。
（1）查看当前CPU物理状态
[root@nginx ~]# lscpu |grep "CPU(s)"
CPU(s): 24 #总的核心数
On-line CPU(s) list: 0-23
每个物理cpu使用的是那些核心（代表2颗物理CPU，）
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23
#本次演示服务器为 两颗物理cpu，每颗物理CPU12个核心, 总共有24个核心
（2）将nginx worker进程绑定至不同的核心上，官方建议与CPU的核心保持一致
# 第一种绑定组合方式（不推荐）
worker_processes 12;
worker_cpu_affinity 000000000001 000000000010 000000000100 000000001000 000000010000 000000100000 000001000000 000010000000 000100000000 001000000000 010000000000 10000000000;
# 第二种方式(使用较少)
worker_processes 2;
worker_cpu_affinity 101010101010 010101010101;
# 第三种最佳绑定方式，修改nginx启动的work进程为自动。
worker_processes auto;
worker_cpu_affinity auto;
（3）查看nginx worker进程绑定至对应cpu
[root@web01 ~]# ps -eo pid,args,psr|grep [n]ginx
1242 nginx: master process /usr/ 2
1243 nginx: worker process 0
1244 nginx: worker process 1
1245 nginx: worker process 2
1246 nginx: worker process 3
5.7 通用优化配置
（1）nginx优化总结，nginx通用优化配置文件
[root@nginx ~]# cat nginx.conf
user www; # nginx进程启动用户
worker_processes auto; #与cpu核心一致即可
worker_cpu_affinity auto; # cpu亲和
error_log /var/log/nginx/error.log warn; # 错误日志
pid /run/nginx.pid; #系统启动之后，会把这个pid放入这个文件里面去
worker_rlimit_nofile 35535; #每个work能打开的文件描述符，调整至1w以上,负荷较高建议2-3w
events {
use epoll; # 使用epoll高效网络模型
worker_connections 10240; # 限制每个进程能处理多少个连接，10240x[cpu核心]
}
http {
include mime.types;
default_type application/octet-stream; # 文件的后缀没有办法解析的话，默认就是下载
charset utf-8; # 统一使用utf-8字符集
# 定义日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#定义json日志格式
log_format json_access '{"@timestamp":"$time_iso8601",'
'"host":"$server_addr",'
'"clientip":"$remote_addr",'
'"size":$body_bytes_sent,'
'"responsetime":$request_time,'
'"upstreamtime":"$upstream_response_time",'
'"upstreamhost":"$upstream_addr",'
'"http_host":"$host",'
'"url":"$uri",'
'"domain":"$host",'
'"xff":"$http_x_forwarded_for",'
'"referer":"$http_referer",'
'"status":"$status"}';
access_log /var/log/nginx/access.log main; # 访问日志
server_tokens off; # 禁止浏览器显示nginx版本号
client_max_body_size 200m; # 文件上传大小限制调整
# 文件高效传输，静态资源服务器建议打开
sendfile on;
tcp_nopush on;
# 文件实时传输，动态资源服务建议打开,需要打开keepalive
tcp_nodelay on;
keepalive_timeout 65;
# Gzip 压缩
gzip on;
gzip_disable "MSIE [1-6]\."; #针对IE浏览器不进行压缩，微软的IE的1-6版本不支持压缩。如果使用你的话，样式变的非常的乱，所以IE访问的不能压缩
gzip_http_version 1.1;
gzip_comp_level 2; #压缩级别
gzip_buffers 16 8k; #压缩的缓冲区
gzip_min_length 1024; #文件大于1024字节才进行压缩，默认值20
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript image/jpeg;
# 虚拟主机
include /etc/nginx/conf.d/*.conf;
}
（2）Nginx安全与优化总结
1.cpu亲和、worker进程数、调整每个worker进程打开的文件数
2.使用epool网络模型、调整每个worker进程的最大连接数
3.文件的高效读取sendfile、nopush、
4.文件的传输实时性、nodealy
5.开启tcp长链接、以及长链接超时时间keepalived
6.开启文件传输压缩gzip
7.开启静态文件expires缓存
8.隐藏Nginx的版本号
9.禁止通过IP地址访问,禁止恶意域名解析,只允许域名访问
10.配置放盗链、以及跨域访问
11.防DDOS、cc攻击, 限制单IP并发连接，以及http请求 # 防DDos、cc攻击用单纯的限制连接单个ip的并发、请求，效果并不好，真的防DDOS、cc要用web应用层硬件防火墙，varf防火墙
12.优雅限制nginx错误页面
13.nginx加密传输https优化
14.nginx proxy_cache、fastcgi_cache、uwsgi_cache缓存
squid、varnish() # varnish做缓存的，开源的http加速器
6. PHP服务优化
（1）/etc/php.ini对解析器进行优化
1.php程序配置管理文件/etc/php.ini，主要调整日志、文件上传、禁止危险函数、关闭版本号显示、等
#;;;;;;;;;;;;;;;;;
# Error logging ; #错误日志设置
#;;;;;;;;;;;;;;;;;
expose_php = Off # 关闭php版本信息
display_error = Off # 屏幕不显示错误日志
error_reporting = E_ALL # 记录PHP的每个错误
log_errors = On # 开启错误日志
error_log = /var/log/php_error.log # 错误日志写入的位置
date.timezone = Asia/Shanghai # 调整时区,默认PRC
#;;;;;;;;;;;;;;;
# File Uploads ; #文件上传设置
#;;;;;;;;;;;;;;;
file_uploads = On # 允许文件上传
upload_max_filesize = 300M # 允许上传文件的最大大小
post_max_size = 300M # 允许客户端单个POST请求发送的最大数据
max_file_uploads = 20 # 允许同时上传的文件的最大数量
memory_limit = 128M # 每个脚本执行最大内存
[Session] #会话共享，做会话保持用的
session.save_handler = redis
session.save_path = "tcp://172.16.1.51:6379"
https://blog.csdn.net/unixtech/article/details/53761832
#php禁止危险函数执行（取决于实际情况，需要和开发沟通）
disable_functions = chown,chmod,pfsockopen,phpinfo
开始实验：
（2）/etc/php-fpm.conf配置文件优化
因为在/etc/php-fpm.conf/下有include=/etc/php-fpm.d/*.conf所以大部分的配置在/etc/php-fpm.d/www.conf文件中
php-fpm进程管理配置文件/etc/php-fpm.conf
#第一部分，fpm配置
;include=etc/fpm.d/*.conf
#第二部分，全局配置
[global]
;pid = /var/log/php-fpm/php-fpm.pid #pid文件存放的位置
;error_log = /var/log/php-fpm/php-fpm.log #错误日志存放的位置
;log_level = error #日志级别, alert, error, warning, notice, debug
rlimit_files = 65535 #php-fpm进程能打开的文件数
;events.mechanism = epoll #使用epoll事件模型处理请求
#第三部分，进程池定义
[www] #池名称
user = www #进程运行的用户
group = www #进程运行的组
;listen = /dev/shm/php-fpm.sock #监听在本地socket文件
listen = 127.0.0.1:9000 #监听在本地tcp的9000端口
;listen.allowed_clients = 127.0.0.1 #允许访问FastCGI进程的IP，any不限制
pm = dynamic #动态调节php-fpm的进程数
pm.max_children = 512 #最大启动的php-fpm进程数
pm.start_servers = 32 #初始启动的php-fpm进程数
pm.min_spare_servers = 32 #最少的空闲php-fpm进程数
pm.max_spare_servers = 64 #最大的空闲php-fpm进程数
pm.max_requests = 1500 #每一个进程能响应的请求数
pm.process_idle_timeout = 15s;
pm.status_path = /phpfpm_status #开启php的状态页面
#第四部分，日志相关
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/phpfpm_error.log
php_admin_flag[log_errors] = on
#慢日志
request_slowlog_timeout = 5s #php脚本执行超过5s的文件
slowlog = /var/log/php_slow.log #记录至该文件中
慢日志示例
[21-Nov-2013 14:30:38] [pool www] pid 11877
script_filename = /usr/local/lnmp/nginx/html/www.quancha.cn/www/fyzb.php
[0xb70fb88c] file_get_contents() /usr/local/lnmp/nginx/html/www.quancha.cn/www/fyzb.php:2
什么时间、什么进程、运行什么文件、哪个函数、第几行达到了超时时间
访问测试phpfpm_status状态页面
php 状态页面 pm.status_path = /phpfpm_status #开启php的状态页面
[root@nginx ~]# curl http://127.0.0.1/phpfpm_status
pool: www #fpm池名称,大多数为www
process manager: dynamic #动态管理phpfpm进程
start time: 05/Jul/2016 #启动时间，如果重启会发生变化
start since: 409 #php-fpm运行时间
accepted conn: 22 #当前池接受的连接数
listen queue: 0 #请求等待队列,如果这个值不为0,那么需要增加FPM的进程数量
max listen queue: 0 #请求等待队列最高的数量
listen queue len: 128 #请求等待队列的长度
idle processes: 4 #php-fpm空闲的进程数量
active processes: 1 #php-fpm活跃的进程数量
total processes: 5 #php-fpm总的进程数量
max active processes: 2 #php-fpm最大活跃的进程数量(FPM启动开始计算)
max children reached: 0 #进程最大数量限制的次数，如果数量不为0，则说明phpfpm最大进程数量过小,可以适当调整。
PHP-FPM配置文件 4核16G、4核32G
[root@nginx ~]# cat /etc/php-fpm.d/www.conf
[global]
pid = /var/run/php-fpm.pid
error_log = /var/log/php-fpm.log
log_level = warning
rlimit_files = 655350
events.mechanism = epoll
[www]
user = nginx
group = nginx
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 512
pm.start_servers = 32
pm.min_spare_servers = 32
pm.max_spare_servers = 64
pm.process_idle_timeout = 15s;
pm.max_requests = 2048
pm.status_path = /phpfpm_status
#php-www模块错误日志
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php/php-www.log
php_admin_flag[log_errors] = on
#php慢查询日志
request_slowlog_timeout = 5s
slowlog = /var/log/php-slow.log # 如果一个php进程运行超过了五秒，会把这个进程记录下来，详细的展示那部分变慢的（比如一个函数运行太慢）
小截图知识：
php默认启动五个进程
7. 自我总结
nginx
硬件层面 代理比较的消耗CPU、内存、 静态比较消耗磁盘IO、
网络层面 网络带宽大小、传输速率、是否有丢包、
系统层面 调整文件描述。 timewait重用
应用层面 nginx作为代理 keepalive 长连接
服务层面 nginx作为静态 浏览器缓存、文件传输、压缩、防盗链、跨域访问、CPU亲和
nginx作为缓存 proxy_cache fastcgi_cache uwsgi_cache
nginx作为安全 nginx+lua实现waf防火墙
php
php.ini 错误日志记录、文件大小的调整、session会话共享的配置、禁止不必要的函数(与开发协商)
php-fpm 监听地址、进程的动态调节、日志开启。
php状态 php自身监控的状态信息
php慢查询 什么时间、什么进程、运行什么文件、哪个函数、第几行达到了超时时间
（1）lsof -p 进程号 看这个进程占用了多少个文件描述符
（2）lsof -i :80 看端口
（3）ulimit -n 查看文件描述符、 gzip -d 解开压缩文件
（4） vim /etc/sevurity/limits.conf
（5）如何知道网络的状态：1. ping命令看丢包率 2. tracert -d -w 2 www.donglinux.com
（6）proxy-cache缓存静态的资源
fastcgi-cache缓存动态的资源
这些不建议使用，如果加了缓存，先去读缓存，缓存在本地磁盘，缓存没有内存处理的快
还会影响速度，如果磁盘特别好的情况下，可以考虑使用cache缓存，缓存都是缓存服务端的本地
不用转发和调度，不用重新的用内存做运算，要读本地的磁盘，如果本地磁盘io特别弱的话，开的话
反而会影响性能，缓存文件存在目录里面是按照级别存的，会存一级目录，二级目录，会一级一级的
遍历，找的时候消耗磁盘的io，磁盘的io又不高，这样的话读缓存还没有直接找后端程序，用内存
做处理快。
nginx作为代理服务，缓存服务要考量的一些参数
（6）截图知识点
这个名字有可能是别人公司的规范：
（7）文件句柄可以理解为inode的索引。
cache-control 浏览器自带的，每次的请求不缓存，都要与服务器进行交互，每次的请求都是过期的
过期了是浏览器还不确定缓存能不能用，需要询问服务端，如果把文件改了，etag会改变