互联网大厂技术-Nginx-初高阶使用技巧及参数详解

目录

Nginx配置

Nginx性能参数详解

Nginx时间详解

1.时间字段定义

1.1.request_time

1.2.upstream_response_time

1.3 $upstream_connect_time(1.9.1)

1.4 $upstream_header_time(1.7.10)

2、场景

2.1 流程说明

2.2 场景举例

Nginx 是一个很强大的高性能Web和反向代理服务，它具有很多非常优越的特性：

在连接高并发的情况下，Nginx是Apache服务不错的替代品：Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一；能够支持高达 50,000 个并发连接数的响应；

Nginx配置

通过可视化的方式描述各个节点含义会更直观

配置示例如下

{
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

Nginx性能参数详解

性能参数

proxy_set_header		设置请求header
client_max_body_size	10m	允许客户端请求的最大单文件字节数
client_body_buffer_size	128k	缓冲区代理缓冲用户端请求的最大字节数
proxy_connect_timeout	90	nginx跟后端服务器连接超时时间(代理连接超时)
proxy_send_timeout	90	后端服务器数据回传时间(代理发送超时)
proxy_read_timeout	90	连接成功后,后端服务器响应时间(代理接收超时)
proxy_buffer_size	4k	设置代理服务器（nginx）保存用户头信息的缓冲区大小
proxy_buffers	4 32k	proxy_buffers缓冲区,网页平均在32k以下的设置
proxy_busy_buffers_size	64k	高负荷下缓冲大小（proxy_buffers*2）
proxy_temp_file_write_size	64k	设定缓存文件夹大小,大于这个值,将从upstream服务器传

Nginx时间详解

1.时间字段定义

1.1.request_time

单位为秒。官网描述：request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client。

指的就是从接受用户请求的第一个字节到发送完响应数据的时间，即$request_time包括接收客户端请求数据的时间、后端程序响应的时间、发送响应数据给客户端的时间(不包含写日志的时间)。

官方文档：Module ngx_http_log_module

1.2.upstream_response_time

单位为秒。官网描述：keeps time spent on receiving the response from the upstream server; the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the $upstream_addr variable.。

是指从Nginx向后端建立连接开始到接受完数据然后关闭连接为止的时间。

从上面的描述可以看出，$request_time肯定比$upstream_response_time值大；尤其是在客户端采用POST方式提交较大的数据，响应体比较大的时候。在客户端网络条件差的时候，$request_time还会被放大。

官方文档：Module ngx_http_upstream_module

除了上述的request_time和upstream_response_time比较常用，在新的Nginx版本中对整个请求各个处理阶段的耗时做了近一步的细分：

1.3 $upstream_connect_time(1.9.1)

单位为秒。keeps time spent on establishing a connection with the upstream server (1.9.1); the time is kept in seconds with millisecond resolution. In case of SSL, includes time spent on handshake. Times of several connections are separated by commas and colons like addresses in the $upstream_addr variable.

跟后端server建立连接的时间，如果是到后端使用了加密的协议，该时间将包括握手的时间。

1.4 $upstream_header_time(1.7.10)

单位为秒。keeps time spent on receiving the response header from the upstream server (1.7.10); the time is kept in seconds with millisecond resolution. Times of several responses are separated by commas and colons like addresses in the $upstream_addr variable.

接收后端server响应头的时间。

2、场景

2.1 流程说明

如果把整个过程补充起来的话 应该是：
［1用户请求］->［2建立 Nginx 连接］->［3发送响应］->［4接收响应］->［5关闭  Nginx 连接］
那么 upstream_response_time 就是 2+3+4+5 
但是 一般这里面可以认为 ［5关闭 Nginx 连接］ 的耗时接近 0
所以 upstream_response_time 实际上就是 2+3+4 

而 request_time 是 1+2+3+4
二者之间相差的就是 ［1用户请求］的时间。

来个网上的图说明情况：

从上图中我们不难得出如下结论

程序真正的运行时间 = $upstream_header_time - $upstream_connect_time
$request_time 中包含了数据返回时间
$request_time 中包含了日志打印的时间

2.2 场景举例

2.2.1 场景

nginx日志出现大量超时报警，这个时候发现$upstream_header_time正常，但是$request_time、$upstream_response_time很大

分析：根据上面的示意图，这个时候便反映出是上游程序执行较慢、或发送数据量大，需要排查执行程序的相关慢日志

2.2.2 场景：

同样是ngxin日志出现大量超时报警，这个时候发现$request_time很大，但是$upstream_response_time正常

分析：$upstream_response_time正常，说明程序执行完毕且正常返回，那么这个时候需要验证是数据返回过慢还是日志打印出现了阻塞。

原因：数据返回慢可以通过抓包分析，通常来说是用户网络原因引起的；日志打印出现阻塞，可能是机器io出现了问题，这个一般很容易发现；还有可能是nginx配置了相关参数，导致了延迟关闭，这里只要根据问题现象一步一步排查即可。也可能返回给客户端是https，大数据加解密耗时

解决方法：

1. 把你的服务器放在high-speed network高性能网络上；
2. 让client能够快速访问；
3. 使用缓存CND、Nginx缓存或者将你的服务器靠近用户，多IDC进行对不同区域用户服务。如：中国IDC、韩国IDC
4. 去掉一些低效率算法，参考：Nagle's algorithm
5. 调整服务器的TCP堆栈（参考  这篇文章）. 然而调整TCP堆栈不会有多大作用，因为内核默认配置已经做了优化调整了。

除了以上举的两个例子，还有各种组合可以分析，

1. 如：$upstream_connect_time很大可能是网络通信出现了问题；
2. 如：$upstream_header_time很小，但是$upstream_response_time很大，可能是数据回写nginx出现了问题。