NGINX基本优化(一)

本文涉及的产品
.cn 域名,1个 12个月
简介:

NGINX基本优化


更改nginx服务默认用户
优化nginx进程对应配置
优化绑定不同的nginx进程到不同cpu,
nginx事件处理模型优化,采用epoll模型
调整优化单个worker进程并发连接数
配置nginx worker进程最大打开文件数
优化服务器域名的hash表大小
开启高效文件传输模式sendfile,设置tcp_nopush参数
优化nginx连接参数调整连接超时时间
上传文件大小(http Request body size)的限制
fastcgi相关参数调优,fastcgi buffer/cache
配置nginx gzip压缩实现性能优化
配置nginx expires缓存实现性能优化
访问日志轮询,不记录某些日志,代理不开访问日志
Nginx站点目录及文件URL访问控制
限制网站来源IP访问


 

1、隐藏版本号优化


http://nginx.org/en/docs/http/ngx_http_core_module.html

 #server_tokensSyntax: server_tokens on | off | string;
Default: server_tokens on;
Context: http, server, location
Enables or disables emitting nginx version in error messages and in the “Server” response header field.

# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Sun, 10 Jul 2016 08:30:40 GMT
Content-Type: text/html
Content-Length: 612Last-Modified: Sun, 15 
May 2016 23:28:20 GMT
Connection: keep-alive
ETag: "57390614-264"Accept-Ranges: bytes

# vi /usr/local/nginx/conf/nginx.conf
# curl -I 192.168.0.82HTTP/1.1 200 OKServer: nginx

 

2、隐藏软件名称


# vi /home/tools/nginx-1.8.1/src/core/nginx.h
13 #define NGINX_VERSION      "1.8.1"      #显示的版本号,修改为想要显示的版本号
14 #define NGINX_VER          "nginx/" NGINX_VERSION    #将nginx修改为想要的软件名称,如GWS
22 #define NGINX_VAR          "NGINX"         #显示的软件名称如如GWS(GTMSWEB SERVER)
23 #define NGX_OLDPID_EXT     ".oldbin"# 
vi /home/tools/nginx-1.8.1/src/http/ngx_http_header_filter_module.c49 static char ngx_http_server_string[] = "Server: nginx" CRLF;    改==> "Server: GTMSWS" CRLF;
# vi /home/tools/nginx-1.8.1/src/http/ngx_http_special_response.c    
 21 static u_char ngx_http_error_full_tail[] =     
 22 "<hr><center>" NGINX_VER "</center>" CRLF     
 23 "</body>" CRLF     
 24 "</html>" CRLF     
 25 ;     
 26      
 27      
 28 static u_char ngx_http_error_tail[] =     
 29 "<hr><center></center>" CRLF   ==》 /     
 30 "</body>" CRLF     
 31 "</html>" CRLF
 
[root@test83 core]# nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313
 (Red Hat 4.4.7-16) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013
 TLS SNI support enabled
 configure arguments: --prefix=/usr/local/nginx-1.8.1 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module



3、更改nginx服务的默认用户

编译时未指定user和group,默认nobody编译时指定,默认即为nginx用户
root@test83 conf]# ps -ef | grep nginx | grep -v grep root       1873      1  0 16:45 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginxnginx      1874   1873  0 16:45 ?        00:00:00 nginx: worker process   

 默认主进程是root,在高标准环境一般设置为普通用户,防止提权。也能使普通用户对服务进行重启等管理

4、优化nginx进程对应配置(worker进程数)


# vi /usr/local/nginx/conf/nginx.conf
worker_processes  1;    #一般cpu核数,后续继续调整,最高一般为2倍 
查看cpu个数信息   top按1 可以看到核数
# grep processor /proc/cpuinfo | wc -l  或者# grep processor -c /proc/cpuinfo    (查看核数)
1    ==>1颗单核
# grep "physical id" /proc/cpuinfo | sort|uniq|wc -l    (cpu个数)


 

5、优化绑定不同的nginx进程到不同cpu,使平均运行(ngx_core_module,实测差不多


默认情况nginx的多个进程有可能跑在某一个或某一核的CPU上,导致nginx进程使用的硬件的资源不均,
本节优化是尽可能地分配不同的nginx进程给不同的CPU处理,达到充分有效利用硬件的多CPU多核资源的目的优化nginx进程对应不同的CPU配置
在优化不同的nginx进程对应不同CPU配置时,四核CPU服务器的参考配置参考如下
worker_processes    4;
worker_cpu_affinity 0001 0010 0100 10000;
#worker_cpu_affinity就是配置nginx进程CPU亲和力的参数,即把不同的进程分配给不同的CPU处理,0001等掩码,分别代表CPU核心,由于worker_processes进程为4,因此,上述配置会把每个进程分配一核CPU处理,默认不会绑定,参数配置为main段

# man taskset   分配cpu功能
NAME
       taskset - retrieve or set a process?[7m<80><99>s CPU affinity
SYNOPSIS
       taskset [options] mask command [arg]...
       taskset [options] -p [mask] pid
举例   task -c 1,2,3 /etc/init.d/mysql start  (多实例可以指定)


 

6nginx事件处理模型优化


nginx的连接处理机制在于不同的操作系统会采用不同的I/O模型,在Linux下,nginx使用epoll的I/O多路复用模型,
在freebsd中使用kqueue的I/O多路复用模型,在solaris中使用/dev/poll方式的I/O多路复用模型,在windows使用的是icop,等等.
要根据系统类型选择不同的事件处理模型,可供使用的选择有
use [kqueue|rtsig|epoll|dev/poll/select|poll];

本次用的是centos6.6,因此我们将nginx的事件处理模型调整为epoll模型
events {               加到main区块event标签,一般nginx已经自动用epoll模式
    worker_connections  1024;    
    use epoll;
}


7、调整优化单个worker进程并发连接数及worker进程最大打开文件数


worker_connections是个时间模块指令,用于定义nginx每个进程的最大并发连接数,默认1024,最大客户端连接数等于worker_processes* worker_connections。
进程的最大连接数也受linux系统进程的最大打开文件数限制,在执行“ulimit -HSn 65535”或配置相应文件后,此设置才生效
events {   
 worker_connections  1024;
 }
 说明:这个连接数包括了所有连接(一个用户请求是两个链接)例如:代理服务器的连接、客户端的连接等,
实际的并发连接数受此参数控制外,还和最大打开文件数worker_rlimit_nofile有关

配置nginx进程最大打开文件数
worker_rlimit_nofile  65535;==>可设置为系统优化后的ulimit -HSn的结果
Syntax: worker_rlimit_nofile number;
Default: —


8、优化服务器域名的hash表大小


确切名字和通配符名字存储在哈希表中。
哈希表和监听端口关联,每个端口都最多关联三张表:确切的名字的哈希表,以星号(*)起始的通配符名字的哈希表和以星号结束的通配符名字的哈希表。
哈希表的尺寸在配置阶段进行了优化,可以以最小的CPU缓存命中失败来找到名字。

nginx首先搜索切确名字的的哈希表,如果没有找到,则搜索以星号(*)其实的通配符名字的哈希表,如果还是没有找到,继续搜索以星号结束的通配符名字的哈希表。
因为名字是按照域名的节点来搜索的。所以搜索通配符名字的哈希表比搜索确切名字的哈希表慢。

注意:nginx.org存储在通配符名字的哈希表中,而不在确切名字的哈希表中。正则表达式是一个一个串行的测试,所以是最慢的,而且不可扩展。
由于上述原因,我们一般尽可能的使用确切的名字。比如如果使用nginx.org和www.nignx.org来访问服务器是最频繁的,那么我们明确的定义出来对访问搜索域名的速度效率来说更有效:
 
如果定义了大量名字,或者定义了非常长的名字,那就需要在php配置模块中调整server_names_hash_max_size    默认512kb,一般是cpu L1的4-5倍,
存放server name的最大哈希表大小server_names_hash_bucket_size  Sets the bucket size for the server names hash tables.
server_names_hash_bucket_size的默认值可能是32,或者是64,或者是其他值,取决于CPU的缓存行的长度。如果这个值是32,那么定义“too.long.server.name.nginx.org”作为虚拟机主机名就会失败,显示如下错误信息:
 could not build the server_names_hash,
 you should increase server_names_hash_bucket_size;32出现这种情况,那就需要设置值扩大一倍:
 http{
  server_names_hash_bucket_size 64;
 }


、开启高效文件传输模式sendfile


sendfile参数用于开启文件的高效传输模式。
同时将tcp_nopush和tcp_nodely两个指令设置为on,可防止网络及磁盘IO阻塞,提升nginx工作效率
http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfileSyntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location
参数作用:激活或者禁用sendfile()功能。sendfile()作用是用于两个文件描述符之间的数据拷贝函数,这个拷贝函数在内核中的,被称为“零拷贝”,
sendfile()比read和write函数要高效很多,因为read和write函数要把数据拷贝到应用层进行操作。相关控制参数还有sendfile_max_chunk

设置tcp_nopush参数
tcp_nopush on
http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nopushSyntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location
参数作用:激活或者禁用linux上的TCP_CORK scoket选项,此选项仅仅当开启sendfile才生效,
激活tcp_nopush参数可以允许把http response header和文件的开始放在一个文件里发布,积极的作用是减少网络报文的数量


10、优化nginx连接参数调整连接超时时间

先来个比喻,饭店请了服务员招待顾客,但是饭店不景气,此时为了节约开支,需要解雇服务员
这里的服务员就相当于nginx服务器建立的连接,当服务器建立的连接没有接收处理请求时,在指定时间内就让它超时自动退出,
还有当nginx和fastcgi服务建立连接请求PHP时,因为有些原因(负载高,停止响应)fastcgi服务无法给nginx返回数据,
此时可以通过配置nginx服务参数,使其不会等死,因为前面用户还等着它返回数据。例如,可设置为如果请求fastcgi,10秒内不能返回数据,
那么nginx就中断本次请求,向用户汇报取不到数据的错误
连接超时的作用:简单来说是一种自我管理,自我保护的重要机制

1、设置将无用的连接尽快超时,可以保护服务器的系统资源(cpu、内存、磁盘)
2、当连接很多时。及时断掉那些已经建立好的但是长时间不做事的连接,减少其占用服务器资源,因为服务器维护连接也是消耗资源的
3、有时黑客或恶意用户攻击网站,就会不断地和服务器建立多个连接,消耗连接数,但是啥也不干,只是持续建立连接,就会大量消耗服务器资源,此时就应该及时断掉这些恶意占用资源的连接
4、lnmp环境中,如果用户请求了动态服务,则nginx就会建立连接请求fastcgi服务以及mysql服务,此时这个nginx连接就要设定一个超时时间,
在用户容忍的时间内返回数据,或者再多等一会后端服务返回数据,具体策略按具体业务分析,当然,后端的fastcgi服务以及mysql服务也有对连接超时的控制
连接超时带来的问题
1、服务器建立新连接也是要消耗资源的,因此,超时设置的太短,就会导致服务器瞬间无法响应用户的请求,导致体验下降
2、企业生产有些PHP程序站点希望设置短连接,因为PHP程序建立连接消耗的资源和时间要少。
而JAVA程序站点一般建立设置长连接,因为java程序建立的连接消耗的资源和时间更多,这是语言运行的机制决定的nginx连接超时的参数设置
1、keepalive_timeout 60;   设置客户端连接保持会话的超时时间为60秒,超过后,服务器会关闭该连接,此数值为参考值 http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requestsSyntax: keepalive_timeout timeout [header_timeout]; Default: keepalive_timeout 75s; Context: http, server, location

2、tcp_nodelay on;激活tcp_nodelay功能,提高IO性能http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nodelaySyntax: tcp_nodelay on | off; Default: tcp_nodelay on; Context: http, server, location
参数作用:默认情况下数据发送时,内核并不会马上发送,可能会等待更多的字节组成一个数据包,这样可以提高IO性能,但是,在每次发送很少字节的业务场景,
使用此功能,等待时间会比较长 生效条件:激活或禁用tcp_nodelay选项,当一个连接进入到keep_alive状态时生效

3、client_header_timeout 15s;设置读取客户端请求头部数据的超时时间。如果超过这个时间客户端还没发送完整的header数据,服务端将返回“Request time out (408)”错误。经验参考值15秒,指定一个超时时间防止客户端利用http协议进行攻击 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeoutSyntax: client_header_timeout time; Default: client_header_timeout 60s; Context: http, server

4、client_body_timeout 15s;设置读取客户端请求主体的超时时间,默认60 http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeoutSyntax: client_body_timeout time; Default: client_body_timeout 60s; Context: http, server, location 参数作用:读取客户端请求主题的超时时间,这个超时仅仅为两次成功的读取操作之间的一个超时,非请求整个主题数据的时间,如在这个超时时间内,客户端没有发送任何数据,nginx将返回“Request time out (408)”错误

5、send_timeout 25s;http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeoutSyntax: send_timeout time; Default: send_timeout 60s; Context: http, server, location 参数作用:设置服务器端传送http响应信息到客户端的超时时间,这个超时时间仅仅为两次成功握手后的一个超时,非请求整个数据的超时时间,在这个超时时间内,客户端没有接受任何数据,连接将被关闭



client_max_body_size
Syntax: tcp_nodelay on | out (Syntax: client_header_timeout Syntax: client_body_timeout  out (Syntax: send_timeout


 

 

11、nginx fastcgi相关参数调优(配合PHP引擎动态服务)


Syntax: fastcgi_connect_timeout time;
Default: fastcgi_connect_timeout 60s;
Context: http, server, location
Defines a timeout for establishing a connection with a FastCGI server. It should be noted that this timeout cannot usually exceed 75 seconds.
表示默认60s,这个参数值通常不要超过75s,因为建立的连接越多消耗的资源就越多


Syntax: fastcgi_send_timeout time;
Default: fastcgi_send_timeout 60s;
Context: http, server, location
Sets a timeout for transmitting a request to the FastCGI server. The timeout is set only between two successive write operations, not for the transmission of the whole request.
 If the FastCGI server does not receive anything within this time, the connection is closed.
设置nginx允许fastcgi服务器端返回数据的超时时间,即,否则,nginx将断开这个连接,默认为60s


Syntax: fastcgi_read_timeout time;
Default: fastcgi_read_timeout 60s;
Context: http, server, location
Defines a timeout for reading a response from the FastCGI server. The timeout is set only between two successive read operations, not for the transmission of the whole response.
 If the FastCGI server does not transmit anything within this time, the connection is closed.
设置nginx从fastcgi服务器端,表示连接建立成功后,nginx等待后端服务器的响应时间,是nginx已经进入后端的排队之中等待处理的时间


Syntax: fastcgi_buffer_size size;
Default: fastcgi_buffer_size 4k|8k;
Context: http, server, location
Sets the size of the buffer used for reading the first part of the response received from the FastCGI server. This part usually contains a small response header. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.
这个是,设定用来读取从fastcgi服务器收到的第一部分,这里的第一部分通常会包含一个小的响应头部,默认情况,这个参数的大小是由fastcgi_buffers指定的一个缓冲区大小。



Syntax: fastcgi_buffers number size;
Default: fastcgi_buffers 8 4k|8k;
Context: http, server, location
Sets the number and size of the buffers used for reading a response from the FastCGI server, for a single connection. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.  
指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求。如果一个PHP脚本所产生的页面大小为256KB,那么会为其分配4个64KB的缓冲区来缓存;
如果页面大小大于256KB,那么大于256KB的部分会缓存到fastcgi_temp指定的路径中,但是这并不是好方法,因为内存中的数据处理速度要快于硬盘。
一般这个值应该为站点中PHP脚本所产生的页面大小的中间值,如果站点大部分脚本所产生的页面大小为256KB,那么可以把这个值设置为“16 16k”、“4 64k”等。


Syntax: fastcgi_busy_buffers_size size;
Default: fastcgi_busy_buffers_size 8k|16k;
Context: http, server, location
When buffering of responses from the FastCGI server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. 
In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file. 
By default, size is limited by the size of two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives.


Syntax: fastcgi_temp_file_write_size size;
Default: fastcgi_temp_file_write_size 8k|16k;
Context: http, server, location
Limits the size of data written to a temporary file at a time, when buffering of responses from the FastCGI server to temporary files is enabled. 
By default, size is limited by two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives. The maximum size of a temporary file is set by the fastcgi_max_temp_file_size directive.


Syntax: fastcgi_temp_path path [level1 [level2 [level3]]];
Default: fastcgi_temp_path fastcgi_temp;
Context: http, server, location
Defines a directory for storing temporary files with data received from FastCGI servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory. 
For example, in the following configuration  fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2;
a temporary file might look like this:
    /spool/nginx/fastcgi_temp/7/45/00000123457
See also the use_temp_path parameter of the fastcgi_cache_path directive.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_temp_path /usr/local/nginx/fastcgi_tmp 1 2;


表示开启FastCGI缓存并为其指定一个名称。开启缓存非常有用,可以有效降低CPU的负载,并且防止502错误的发生,但是开启缓存也会引起很多问题,要视具体情况而定。
为FastCGI缓存指定一个文件路径、目录结构等级、关键字区域存储时间和非活动删除时间
Syntax: fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] 
[manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] 
[loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default: —
Context: http


 

 


12、配置nginx gzip压缩实现性能优化


 

    }

本文转自写个博客骗钱博客51CTO博客,原文链接http://blog.51cto.com/dadonggg/1950648如需转载请自行联系原作者


菜鸟东哥

相关文章
|
应用服务中间件 nginx
nginx优化:URI过长或request header过大导致400或414报错
当出现URI过长或请求头过大导致400或414报错时,可以通过以下方式对Nginx进行优化: 1. 调整client_max_body_size参数:该参数用于限制请求体的大小。默认情况下,Nginx的client_max_body_size参数设置为1M。如果请求体超过这个大小,Nginx会返回400错误。您可以根据实际需求适当增加这个值,例如设置为10M或更大。 ``` http { client_max_body_size 10M; } ``` 2. 调整large_client_header_buffers参数:该参数用于调整请求头缓冲区的大
3987 0
|
应用服务中间件 Linux PHP
深入理解Nginx工作原理及优化技巧(上)
深入理解Nginx工作原理及优化技巧
深入理解Nginx工作原理及优化技巧(上)
|
2月前
|
缓存 前端开发 JavaScript
|
2月前
|
缓存 监控 负载均衡
nginx相关配置及高并发优化
Nginx的高并发优化是一个综合性的过程,需要根据具体的业务场景和硬件资源量身定制。以上配置只是基础,实际应用中还需根据服务器监控数据进行持续调整和优化。例如,利用工具如ab(Apache Benchmarks)进行压力测试,监控CPU、内存、网络和磁盘I/O等资源使用情况,确保配置的有效性和服务的稳定性。
124 0
|
4月前
|
负载均衡 应用服务中间件 网络安全
Django后端架构开发:Nginx服务优化实践
Django后端架构开发:Nginx服务优化实践
61 2
|
4月前
|
缓存 前端开发 Java
"揭秘!SpringBoot携手Nginx,性能飙升秘籍大公开:轻松掌握配置优化,让你的应用快如闪电!"
【8月更文挑战第11天】随着微服务架构的发展,SpringBoot成为构建RESTful API的首选,Nginx则作为高性能的反向代理服务器提升应用性能。本文将探讨两者如何协同工作,包括Nginx的负载均衡策略、静态资源缓存及数据压缩配置;同时讨论SpringBoot的线程池优化、缓存策略及性能监控。通过这些方法,帮助开发者显著提高系统的整体性能和可用性。
161 1
|
5月前
|
缓存 负载均衡 应用服务中间件
Nginx反向代理优化
教你如何做好Nginx反向代理优化
108 5
|
6月前
|
监控 前端开发 应用服务中间件
前端开发者必备:Nginx入门实战宝典,从部署到优化一网打尽(2)
前端开发者必备:Nginx入门实战宝典,从部署到优化一网打尽
87 1
|
6月前
|
负载均衡 前端开发 应用服务中间件
前端开发者必备:Nginx入门实战宝典,从部署到优化一网打尽(1)
前端开发者必备:Nginx入门实战宝典,从部署到优化一网打尽
183 1
|
7月前
|
缓存 负载均衡 安全
深入探索Nginx高性能Web服务器配置与优化
【5月更文挑战第7天】本文深入探讨了Nginx的配置与优化,重点介绍了基础配置参数如`worker_processes`、`worker_connections`和`keepalive_timeout`,以及优化策略,包括使用epoll事件驱动模型、开启gzip压缩、启用缓存、负载均衡和安全配置。此外,还提到了性能调优工具,如ab、nginx-stats和nmon,以助于提升Nginx的性能和稳定性。