Nginx 部分 (三) - 性能管理-配置解析

话题锋转,关于配置部分的信息,对于部分(一),可能对于配置一十分蒙,对这些配置十分无奈,这章是用来解析这些配置的,留存笔记,传递知识。



该用多少线程:


工作进程

worker_process指令会指定:应该运行多少个 worker。默认情况下,此值设置为 1。最安全的设置是通过传递 auto 选项来使用核心数量。

worker_process auto;

worker 连接

与 worker_process 直接绑定的指令是 worker_connections。它指定一个工作进程可以一次打开多少个连接。这个数目包括所有连接(例如与代理服务器的连接)

,而不仅仅是与客户端的连接。(此外,值得记住的是,一个客户端可以打开多个连接,同时获取其他资源)

worker_connections 1024;

打开文件数目限制

在基于 Unix 系统中的“一切都是文件”。这意味着文档、目录、管道甚至套接字都是文件。系统对一个进程可以打开多少文件有一个限制。要查看该限制

ulimit -Sn      # soft limit	软件限制
ulimit -Hn      # hard limit	硬件限制


这个系统限制必须根据 worker_connections 进行调整。任何传入的连接都会打开至少一个文件(通常是两个连接套接字以及后端连接套接字或磁盘上的静态文件) 。所

以这个值等于 worker_connections*2 是安全的。幸运的是,Nginx 提供了一个配置选项来增加这个系统的值。要使用这个配置,请添加具有适当数目的 worker_rlimit_nofile

指令并重新加载 nginx

worker_rlimit_nofile 2048;

配置

worker_process auto;
worker_rlimit_nofile 2048; # Changes the limit on the maximum number of open files (RLIMIT_NOFILE) for worker processes.
worker_connections 1024;   # Sets the maximum number of simultaneous connections that can be opened by a worker process
最大连接数(计算)

最大连接数 = 
 
    worker_processes * worker_connections
----------------------------------------------
 (keep_alive_timeout + avg_response_time) * 2

keep_alive_timeout (后续有更多介绍) +avg_response_time告诉我们:单个连接持续了多久。我们也除以 2,通常情况下,d将有一个客户端打开 2 个连接的情况:

一个在 nginx 和客户端之间,另一个在 nginx 和上游服务器之间。



Gzip 

启用 gzip 可以显著降低响应的(报文)大小,因此,客户端(网页)会显得更快些。
(Gzip 有不同的压缩级别,1 到 9 级。递增这个级别将会减少文件的大小,但也会增加资源消耗。作为标准我们将这个数字(级别)保持在 3 – 5 级,就像上面说的那样,它将会得到较小的节省,同时也会得到更大的 CPU 使用率)

gzip_http_version 1.1;
这条指令告诉 nginx 仅在 HTTP 1.1 以上的版本才能使用 gzip。我们在这里不涉及 HTTP 1.0,至于 HTTP 1.0 版本,它是不可能既使用 keep-alive 和 gzip 的。 因此你必须
做出决定:使用 HTTP 1.0 的客户端要么错过 gzip,要么错过 keep-alive。
配置

gzip on;               # enable gzip
gzip_http_version 1.1; # turn on gzip for http 1.1 and above
gzip_disable "msie6";  # IE 6 had issues with gzip
gzip_comp_level 5;     # inc compresion level, and CPU usage
gzip_min_length 100;   # minimal weight to gzip file
gzip_proxied any;      # enable gzip for proxied requests (e.g. CDN)
gzip_buffers 16 8k;    # compression buffers (if we exceed this value, disk will be used instead of RAM)
gzip_vary on;          # add header Vary Accept-Encoding (more on that in Caching section)
 
# define files which should be compressed
gzip_types text/plain;
gzip_types text/css;
gzip_types application/javascript;
gzip_types application/json;
gzip_types application/vnd.ms-fontobject;
gzip_types application/x-font-ttf;
gzip_types font/opentype;
gzip_types image/svg+xml;
gzip_types image/x-icon;


参数说明:

gzip
决定是否开启gzip模块
param:on|off
example:gzip on;

gzip_buffers 
设置gzip申请内存的大小,其作用是按块大小的倍数申请内存空间
param1:int 多少倍
param2:int(k) 后面单位是k
example: gzip_buffers 4 8k; //4倍的大小申请8k内存空间

gzip_comp_level
设置gzip压缩等级,等级越底压缩速度越快文件压缩比越小,反之速度越慢文件压缩比越大
param:1-9
example:gzip_com_level 1;

gzip_min_length
当返回内容大于此值时才会使用gzip进行压缩,以K为单位,当值为0时,所有页面都进行压缩
param:int
example:gzip_min_length 1000;

gzip_http_version
用于识别http协议的版本,早期的浏览器不支持gzip压缩,用户会看到乱码,所以为了支持前期版本加了此选项,目前此项基本可以忽略
param: 1.0|1.1
example:gzip_http_version 1.0

gzip_proxied
Nginx做为反向代理的时候启用,
param:off|expired|no-cache|no-sotre|private|no_last_modified|no_etag|auth|any]
expample:gzip_proxied no-cache;
off – 关闭所有的代理结果数据压缩
expired – 启用压缩,如果header中包含”Expires”头信息
no-cache – 启用压缩,如果header中包含”Cache-Control:no-cache”头信息
no-store – 启用压缩,如果header中包含”Cache-Control:no-store”头信息
private – 启用压缩,如果header中包含”Cache-Control:private”头信息
no_last_modified – 启用压缩,如果header中包含”Last_Modified”头信息
no_etag – 启用压缩,如果header中包含“ETag”头信息
auth – 启用压缩,如果header中包含“Authorization”头信息
any – 无条件压缩所有结果数据

gzip_vary

语法:gzip_vary on|off
默认:gzip_vary off;
功能:表示是否添加"Vary: Accept-Encoding"响应头




缓存

缓存是另一回事,它能提升用户的请求速度。


  • 在 HTTP/1.1 中用 Cache-Control 管理缓存
  • Pragma 对于 HTTP/1.0 客户端的向后兼容性
缓存本身可以分为两类: 公共缓存和私有缓存
公共缓存是被多个用户共同使用的。
专用缓存专用于单个用户。

我们可以很容易地区分,应该使用哪种缓存:
add_header Cache-Control public;
add_header Pragma public;

例如对于标准资源,我们想保存1个月:
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
  expires 1M;
  add_header Cache-Control public;
  add_header Pragma public;
}
ps:

expires 30s; //表示把数据缓存30秒

expires 30m;//表示把数据缓存30分

expires 10h;//表示把数据缓存10小时

expires 1d;//表示把数据缓存1天

expires 1M;//表示把数据缓存一个月

然而我们最终配置如下:
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
  expires 1M;
  add_header Cache-Control public;
  add_header Pragma public;
  add_header Vary Accept-Encoding;//后面详解
}

因为第一段存在一个问题:

使用公共缓存时有一个注意事项。让我们看看如果将我们的资源存储在公共缓存(如 CDN)中,URI 将是唯一的标识符。在这种情况下,我们认为 gzip 是开启的。

假设有2个浏览器:

  • 旧的,不支持 gzip

  • 新的,支持 gzip


旧的浏览器给 CDN 发送了一个 netguru.co/style 请求。但是 CDN 也没有这个资源,它将会给我们的服务器发送请求,并且返回未经压缩的响应。 CDN 在哈希里存储文件

(为以后使用):

{
  ...
  netguru.co/styles.css => FILE("/sites/netguru/style.css")
  ...
}

然后将其返回给客户端。

现在,新的浏览器发送相同的请求到 CDN,请求 netguru.co/style.css,获取 gzip 打包的资源。由于 CDN 仅通过 URI 标识资源,它将为新浏览器返回一样的未压缩资源。

接着新的浏览器将尝试提取未打包的文件,但是将获得无用的东西。

如果我们能够告诉公共缓存是怎样进行 URI 和编码的资源识别,我们就可以避免这个问题:
{
  ...
  (netguru.co/styles.css, gzip) => FILE("/sites/netguru/style.css.gzip")
  (netguru.co/styles.css, text/css) => FILE("/sites/netguru/style.css")
  ...
}

这正是 Vary Accept-Encoding: 完成的。它告诉公共缓存,可以通过 URI 和 Accept-Encoding header 区分资源,故我们会做成以上那配置。


超时
client_body_timeoutclient_header_timeout 定义了 nginx 在抛出 408(请求超时)错误之前应该等待客户端传输主体或头信息的时间。

send_timeout 设置向客户端发送响应的超时时间。超时仅在两次连续的写入操作之间被设置,而不是用于整个响应的传输过程。如果客户端在给定时间内没有收到任何内容,则连接将被关闭。


设置这些值时要小心,因为等待时间过长会使你容易受到攻击者的攻击,并且等待时间太短的话会切断与速度较慢的客户端的连接
# Configure timeouts
client_body_timeout   12;
client_header_timeout 12;
send_timeout          10;


Buffers
client_body_buffer_size
设置读取客户端请求正文的缓冲区大小。如果请求主体大于缓冲区,则整个主体或仅其部分被写入临时文件。对 client_body_buffer_size 而言,设置 16k 大小在大多数 
情况下是足够的。
注意这是又一个可以产生巨大影响的设置,必须谨慎使用。太小了,则 nginx 会不断地使用 I/O 把剩余的部分写入文件。太大了,则当攻击者可以打开所有连接但你无法在系统上分配足够缓冲来处理这些连接时,你可能容易受到 DOS 攻击。


client_header_buffer_size 和 large_client_header_buffers
如果 header 不能跟 client_header_buffer_size 匹配上,就会使用large_client_header_buffers。如果请求也不适合 large_client_header_buffers,将给客户端返回一个错误提示。对于大多数的请求来说,1KB 的缓存是足够的。但是,如果一个包含大量记录的请求,1KB 是不够的。
如果请求行的长度超限,将给客户端返回一个 414(请求的 URI 太长)错误提示。如果请求的 header 长度超限,将抛出一个 400(错误请求)的错误代码

client_max_body_size
设置客户端请求主体的最大允许范围,在请求头字段中指定“内容长度”。如果您希望允许用户上传文件,调整此配置以满足您的需要。
配置:
client_body_buffer_size       16K;
client_header_buffer_size     1k; #如果请求头总长度大于小于1k,则使用此缓冲区,请求头总长度大于1k时使用large_client_header_buffers设置的缓存区
large_client_header_buffers   2 1k;#指令参数2为个数,1k为大小,默认是8k。申请4个128k。
client_max_body_size          8m;

Keep-Alive
HTTP 所依赖的 TCP 协议需要执行三次握手来启动连接。这意味着在服务器可发送数据(例如图像)之前,需要在客户机和服务器之间进行三次完整的往返

假设你从 Warsaw 请求的 /image.jpg,并连接到在柏林最近的服务器:
Open connection
 
TCP Handshake:
Warsaw  ->------------------ synchronize packet (SYN) ----------------->- Berlin
Warsaw  -<--------- synchronise-acknowledgement packet (SYN-ACK) ------<- Berlin
Warsaw  ->------------------- acknowledgement (ACK) ------------------->- Berlin
 
Data transfer:
Warsaw  ->---------------------- /image.jpg --------------------------->- Berlin
Warsaw  -<--------------------- (image data) --------------------------<- Berlin
 
Close connection
对于另一次请求,你将不得不再次执行整个初始化。如果你在短时间内发送多次请求,这可能会快速累积起来。这样的话 keep-alive 使用起来就方便了。在成功响应之后
,它保持连接空闲给定的时间段(例如 10 秒)。如果在这段时间内有另一个请求,现有的连接将被重用,空闲时间将被刷新。

Nginx 提供了几个指令来调整 keepalive 设置。这些可以分为两类:

在客户端和 nginx 之间 keep-alive
keepalive_disable msie6;        # disable selected browsers.
 
# The number of requests a client can make over a single keepalive connection. The default is 100, but a much higher value can be especially useful for
 testing with a load‑generation tool, which generally sends a large number of requests from a single client.keepalive_requests 100000;
# How long an idle keepalive connection remains open.keepalive_timeout 60;
 
  在 nginx 和上游服务器之间 keep-alive 
 
upstream backend {
    # The number of idle keepalive connections to an upstream server that remain open for each worker process
    keepalive 16;
}
 
server {
  location /http/ {
    proxy_pass http://http_backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }
}


猜你喜欢

转载自blog.csdn.net/coffeeandice/article/details/79311043
今日推荐