46-Nginx性能优化

性能优化概述

1、首先我们需要了解性能优化要考虑哪些方面。
2、然后我们需要了解性能优化必要用到的压力测试工具ab
3、最后我们需要了解系统上有哪些注意和优化的点，以及nginx配置文件

我们再做性能优化工作前，我们重点需要考虑哪些方面和了解哪些方面

1、首先需要了解我们当前系统的结构和瓶颈，了解当前使用的是什么，运行的是什么业务，都有哪些服务，了解每个服务最大能支撑多少并发。比如nginx作为静态资源服务并发是多少，最高瓶颈在哪里，能支持多少qps（每秒查询率）的访问请求，那我们怎么得出这组系统结构瓶颈呢，比如top查看系统的CPU负载、内存使用率、总得运行进程等，也可以通过日志去分析请求的情况，当然也可以通过我们前面介绍到的stub_statius模块查看当前的连接情况，也可以对线上的业务进行压力测试（低峰期），去了解当前这套系统能承担多少的请求和并发，已做好响应的评估。这个是我们做性能优化最先考虑的地方。

2、其次我们需要了解业务模式，虽然我们是做性能优化，但每一个性能的优化都是为业务所提供的服务的，我们需要了解每个业务接口的类型，比如：电商网站中的抢购模式，这种情况下面，平时没什么流量，但到了抢购时间流量会突增。
我们还需要了解系统层次化的结构，比如：我们使用nginx做的是代理、还是动静分离、还是后端直接服务用户，那么这个就需要我们对每一层做好相应的梳理。以便更好的服务业务。

3、最后我们需要考虑性能与安全，往往注重了性能，但是忽略了安全。往往过于注重安全，对性能又会产生影响。比如：我们在设计防火墙功能时，检测过于严密，这样就会给性能带来影响。那么如果对于性能完全追求，却不顾服务的安全，这个也会造成很大的隐患，所以需要评估好两者的关系，把握好两者的孰重孰轻。以及整体的相关性，权衡好对应的点。

从OSI模型考虑优化方向：
> 硬件 代理（CPU） 静态（磁盘IO） 动态（CPU、内存）
> 网络 贷款 丢包 延迟
> 系统 文件描述（文件句柄数）
> 应用 服务与服务保持长连接 http1.1
> 服务 静态资源优化

压力测试工具

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

安装ab压力测试工具：
yum install httpd-tools -y

[root@web01 ~]# ab -n 200 -c 2 http://127.0.0.1/

#-n 要执行的请求数
#-c 请求的并发数
#-k 是否开启长连接

配置Nginx静态网站

[root@web01 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;
    }
}

[root@web01 conf.d]# echo "nginx ab" > /code/ab.html
[root@web01 conf.d]# ab -n 10000 -c 200 http://try.oldboy.com/ab.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 try.oldboy.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        nginx/1.26.0		#测试服务器的名字
Server Hostname:        try.oldboy.com		#请求的URL主机名字
Server Port:            80					#请求的端口

Document Path:          /ab.html			#请求路径
Document Length:        9 bytes				#HTTP响应的正文长度

Concurrency Level:      200					#并发用户数，这是我们设置的参数之一
Time taken for tests:   3.334 seconds		#所有的这些请求被处理完成的所花费的时间 单位秒
Complete requests:      10000				#总请求数这是我们设置的参数之一
Failed requests:        0					#表示失败的请求数量
Write errors:           0					#
Total transferred:      2380000 bytes		#所所有请求的响应数据长度总和。包括每个HTTP响应数据的头信息和正文数据的长度
HTML transferred:       90000 bytes			#所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度
Requests per second:    2999.25 [#/sec] (mean)	 #吞吐量。计算公式Complete requests/Time taken for tests  总请求数/处理完成这些请求数所花费的时间
Time per request:       66.683 [ms] (mean)	#用户平均等待时间，
Time per request:       0.333 [ms] (mean, across all concurrent requests)	#服务器平均请求等待时间
Transfer rate:          697.09 [Kbytes/sec] received	  #表示这些请求在单位时间内从服务器获取的数据长度

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   22  15.9     23    1021
Processing:    17   44   8.4     43      63
Waiting:        1   30   4.8     30      41
Total:         21   66  16.7     67    1070

Percentage of the requests served within a certain time (ms)
  50%     67
  66%     69
  75%     71
  80%     71
  90%     76
  95%     82
  98%     86
  99%     87
 100%   1070 (longest request)

影响性能的指标

1、网络
    （1）网络的流量
    （2）网络是否丢包
    （3）这些会影响http的请求与调用
2、系统
    （1）硬件有没有磁盘损坏，磁盘速率
    （2）系统的负载、内存、系统稳定性
3、服务
    （1）连接优化。请求优化
    （2）根据业务形态做对应的服务设置
4、程序
    （1）接口性能
    （2）处理速度
    （3）程序执行效率
5、数据库

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

系统性能优化

文件句柄，Linux一切皆文件，文件句柄可以理解为就是一个索引，文件句柄会随着我们进程的调用频繁增加，系统默认文件句柄是有限制的，不能让一个进程无限的调用，所以我们需要限制每个 进程和每个服务使用多大的文件句柄，文件句柄也是必须要调整的优化参数。

文件句柄的设置方式：
1、系统全局性修改。
2、用户局部性修改。
3、进程局部性修改。

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    #可以查看所有内核参数

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

为什么我们要关注这个高并发短连接呢？有两个方面需要注意：
\1. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
\2. 在这个场景中，短连接表示业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间的连接。

这里有个相对长短的概念，比如取一个web页面,1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高。

禁止时间戳

代理服务优化

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

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;	#获取真实客户端的IP地址
        proxy_set_header X-Forwared-For $proxy_add_x_forwarded_for;		##获取真实客户端的IP地址
        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响应的数量和大小
    ...
    }
}