优化Nginx服务的worker进程个数
修改nginx主配置文件
worker_processes 1; #指定了Nginx要开启的进程数，结尾数字就是进程个数
Nginx有Master进程和worker进程之分，Master为管理进程，真正接待“顾客”的是worker进程。
优化Nginx进程个数的策略
(1)worker_processes参数大小的设置最好和网站的用户数量相关联，
(2)新搭建服务器时，worker进程数最开始的设置可以等于CPU的核数,高流量高并发场合也可以考虑将进程数提高至CPU核数*2
查看Web服务器CPU硬件资源信息
通过/proc/cpuinfo可查看CPU个数及总核数。查看CPU总核数的示例如下:
grep processor /proc/cpuinfo processor : 0 processor : 1 processor : 2 processor : 3 grep processor /proc/cpuinfo | wc -l 4 #表示为1颗CPU四核
#查看CPU总颗数示例如下： grep "physical id" /proc/cpuinfo physical id : 0 #物理ID一致，同一颗CPU physical id : 0 #物理ID一致，同一颗CPU physical id : 0 #物理ID一致，同一颗CPU physical id : 0 #物理ID一致，同一颗CPU grep "physical id" /proc/cpuinfo | sort | uniq | wc -l 1 #去重复，表示1颗CPU
修改重启后的worker进程数量，如下：
ps -ef | grep "nginx" | grep -v grep root 1110 1 0 11:12 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx nginx 1429 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1430 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1431 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1432 1110 0 11:33 ? 00:00:00 nginx: worker process
从“worker_processes 4”可知，worker进程数为4个。Nginx Master主进程不包含在这个参数内，Nginx Master的主进程为管理进程，负责调度和管理worker进程。
Nginx事件处理模型优化
在Linux下，Nginx使用epoll的I/O多路复用模型，在Freebsd中使用kqueue的I/O多路复用模型，在Solaris中使用/dev/poll方式的I/O多路复用模型，在Windows中使用的是icop，等等。
也可以不指定事件处理模型，Nginx会自动选择最佳的事件处理模型服务。
#具体的配置参数如下：
events #events指令是设定Nginx的工作模式及连接数上限
{
use epoll； #use是一个事件模块指令，用来指定Nginx的工作模式。Nginx支持的工作模式有select，poll，kqueue，epoll，rtsig和/dev/poll。 其中select和poll都是标准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系统中。 对于Linux系统Linux2.6+内核，推荐选择epoll工作模式，这是高性能高并发的设置
}
调整Nginx单个进程允许的客户端最大连接数
调整Nginx单个进程允许的客户端最大连接数,控制参数为work_connections。 (worker_connections的值要根据具体服务器性能和程序的内存使用量来指定)
events #events指令是设定Nginx的工作模式和连接数上线
{
worker_connections 20480;
#worker_connections也是个事件模块指令，用于定义Nginx每个进程的最大连接数，默认是1024.最大客户端连接数由worker_processes和worker_connections决定， 即Max_client= worker_processes*worker_connections。进程的最大连接数受Linux系统进程的最大打开文件数限制，在执行操作系统命令 “ulimit -HSn 65535”或配置相应文件后，worker_connections的设置才能生效。
}
实际的并发连接数除了受worker_connections参数控制外，还和最大打开文件数worker_rlimit_nofile有关，Nginx总并发连接=worker数量*worker_connections。
配置Nginx worker进程最大打开文件数
worker_rlimit_nofile 65535; #最大打开文件数，可设置为系统优化后的ulimit -HSn的结果
放置位置：主标签段 此参数的作用是改变worker processes能打开的最大文件数
开启高效文件传输模式
http模块
设置参数1：sendfile on; #激活或禁用sendfile()功能功能。
#sendfile参数用于开启文件的高效传输模式。同时将tcp_nopush和tcp_nodelay两个指令设置为on，可防止网络及磁盘I/O阻塞，提升Nginx工作效率。
设置参数2：tcp_nopush on; #激活或禁用Linux上的TCP_CORK socket选项，此选项仅仅当开启sendfile时才生效,允许把http response header和文件的开始部分放在一个文件里发布，作用是减少网络报文段的数量。
优化Nginx连接参数，调整连接超时时间
连接超时的作用
(1)将无用的连接设置为尽快超时，可以保护服务器的系统资源
(2)当连接很多时，及时断掉那些已经建立好的但又长时间不做事的连接，以减少其占用的服务器资源
(3)黑客攻击网站，就会不断地和服务器建立多个连接，消耗连接数，大量消耗服务器的资源.
(4)LNMP环境中，如果用户请求了动态服务，则Nginx就会建立连接，请求FastCGI服务以及后端MySQL服务,，后端的FastCGI服务及MySQL服务也有对连接的超时控制。
不同程序连接设定知识
服务器建立新连接也是要消耗资源的，因此，超时设置得太短而并发很大，就会导致服务器瞬间无法响应用户的请求，导致用户体验下降。
PHP程序站点设置成短连接，PHP程序建立连接消耗的资源和时间相对要少些。对于Java程序站点来说，一般建议设置长连接，因为Java程序建立连接消耗的资源和时间更多.
Nginx连接超时的参数设置
在http模块
设置参数(1)：keepalive_timeout 60; #保持会话的超时时间为60秒
设置参数(2)：tcp_nodelay on; #用于激活tcp_ondelay功能，提高I/O性能。
默认情况下当数据发送时，内核并不会马上发送，可能会等待更多的字节组成一个数据包，这样可以提高I/O性能。使用tcp_nodelay功能，等待时间会比较长。
设置参数(3)：client_header_timeout 15; #设置读取客户端请求头数据的超时时间
设置读取客户端请求头数据的超时时间。服务器端将返回“Request time out (408)”错误，可指定一个超时时间，防止客户端利用http协议进行攻击。
设置参数(4)：client_body_timeout 15; #用于设置读取客户端请求主体的超时时间，默认值60
设置参数(5)：send_timeout 25; #用于指定响应客户端的超时时间。
上传文件大小的限制
调整上传文件的大小
在Nginx主配置文件里加入如下参数：
client_max_body_size 8m; #具体大小根据公司的业务做调整，如果不清楚就先设置为8m.
设置最大的允许的客户端请求主体大小，在请求头域有“Content-Length”，如果超过了此配置值，客户端会受到413错误，设置为0表示禁止检查客户端请求主体大小。
FastCGI相关参数调优
Nginx FastCGI客户端向后请求PHP动态引擎服务（php-fpm（FastCGI服务器端）
fastcgi_connect_timeout ; #表示Nginx服务器和后端FastCGl服务器连接的超时时间，默认值为60fastcgi_ connect. timeout 秒，这个参数值通常不要超过75秒，因为建立的连接越多，消耗的资源就越多
fastcgi_send_timeout ; #设置Nginx允许FastCG1服务器端返回数据的超时时间，即在规定时间之fastcgi_ send. timeout 内后端服务器必须传完所有的数据，否则，Nginx将断开这个连接。其默认值为60秒
fastcgi_read_timeout ; #设置Nginx从FastCGl服务器端读取响应信息的超时时间，表示连接建立fastcgi_ read_ timeout 成功后，Nginx等待后嶺服务器的响应时间，是Nginx已经进人后端的排队之中等候处理的时间
fastcgi_buffer_size 64k; #这是Nginx FastCGl的缓冲区大小参数，设定用来读取以FastCGl服务器端收到的第-一部分响应信息的缓冲区大小，这里的第-部分通常会包含-一个fastcgi_ buffer. size小的响应头部。默认情况下，这个参数的大小是由fastegi buffers 指定的一个缓冲区的大小
fastcgi_buffers 4 64k; #设定用来读取从FastCGl服务器端收到的响应信息的缓冲区大小和缓冲区数量，默认值为fastcgi buffers 8 4k{8k;。指定本地需要用多少和多大的缓冲区来缓冲FastCGl的应答请求。如果一个PHP脚本所产生的页面大小为256KB，那么会为其分配4个64KB的缓fastcgi_ buffers 冲区来缓存;如果页面大小大于256KB.那么大于256KB的部分会缓存到fastcgi temp 指定的路径中，但是这并不是好方法，因为内存中的数据处理速度要快于硬盘。一般这个值应该为站点中PHP脚本所产生的页面大小的中间值，如果站点大部分脚本所产生的页面大小为256KB,那么可以把这个值设置为“1616k”, "464k”等
proxy_busy_buffers_size ; #用于设置系统很忙时可以使用的proxy_ buffers大小，官方推荐的大小为proxy_ buffers*2
fastcgi_busy_buffers_size ; #用于设置系统很忙时可以使用的fastcgibuffers大小，官方推荐的大小为fastcgi_ buffers*2
fastcgi_temp_file_write_size ; #FastCGI临时文件的大小,可设为128~256KB
fastcgi_cache_valid ; #示例: fastcgi cache_ valid 200 302 1h;用来指定应答代码的缓存时间，实例中的值表示将200和302应答缓存一个小时。示例: fastcgi_ cache_ valid 301 ld;将301应答缓存1天。示例: fastcgi_ cache_ valid any 1m,将其他应答缓存设置为1分钟
fastcgi_ cache_ min_ uses; #示例: fastcgi_ cache_ min_ uses 1;设置请求几次之后响应将被缓存，1表示一次即被缓存
fastcgi_ cache_ use_ stale; # 示例: fastcgi_ cache_ use_ stale error timeout invalid_ header http_ 500;定义在哪些情况下使用过期缓存
fastcgi_ cache_ key; #示例: fastcgi_ cache_ key $request_ method://$host$request_ uri;fastcgi_ cache_ key http://$host$request uri;定义fastcgi cache的key,示例中以请求的URI作为缓存的key, Nginxfastcgi_ cache_ key 会取这个key的md5作为缓存文件，如果设置了缓存散列目录，Nginx会从后往前取相应的位数做为目录。注意一定要加上$request_ method 作为cache key, 否则如果先请求的为head类型，后面的GET请求返回为空
Nginx gzip压缩实现性能优化
Nginx gzip压缩功能介绍
Nginx gzip压缩模块提供了压缩文件内容的功能,Nginx服务器会根据一些具体的策略实施压缩，以节约网站出口带宽，同时加快数据传输效率，来提升用户访问体验。
Nginx gzip压缩的优点
(1)提升网站用户体验;发送给用户的内容小了，用户访问单位大小的页面就加快了，用户体验提升了
(2)节约网站带宽成本：数据是压缩传输的，因此节省了网站的带宽流量成本，不过压缩时会稍微消耗一些CPU资源，这个一般可以忽略。
#此功能既能提升用户体验，又能使公司少花钱，一举多得。对于几乎所有的Web服务来说，这是一个非常重要的功能，Apache服务也有此功能。
需要和不需要压缩的对象
纯文本内容压缩比很高，纯文本的内容最好进行压缩，例如：html，js，css，xml，shtml等格式的文件。
被压缩的纯文本文件必须要大于1KB.
图片，视频（流媒体）等文件尽量不要压缩，因为这些文件大多都是经过压缩的，
原文地址：https://www.cnblogs.com/ywrj/p/9388925.html