大多数使用场景下，Nginx默认配置表现较好，然而如果想挤压出Nginx的性能，就需要了解哪些指令会影响Nginx性能.

1.SSL

当SSL性能至关重要时，最好在环境中尝试不同的密钥大小和类型，找到适合的特定安全需求的正确平衡，以提高安全性，缩短密钥以获得更快的性能。

简单的测试是从传统的RSA密钥转移到椭圆曲线密码术（ECC），它使用更小的密钥大小，所以在相同的安全级别上计算速度更快。

常见的密钥交换算法特性如下：

RSA：算法实现简单，诞生于 1977 年，历史悠久，经过了长时间的破解测试，安全性高。缺点就是需要比较大的素数（目前常用的是 2048 位）来保证安全强度，很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。

DH：diffie-hellman 密钥交换算法，诞生时间比较早（1977 年），但是 1999 年才公开。缺点是比较消耗 CPU 性能。

ECDHE：使用椭圆曲线（ECC）的 DH 算法，优点是能用较小的素数（256 位）实现 RSA 相同的安全等级。缺点是算法实现复杂，用于密钥交换的历史不长，没有经过长时间的安全攻击测试。

ECDH：不支持 PFS，安全性低，同时无法实现 false start。

DHE：不支持 ECC。非常消耗 CPU 资源。

2.Gzip压缩

启用gzip可以节省带宽 ，从而缩短慢速连接的页面加载时间。提高访问速度, 进而优化Nginx性能!

对于图片，视频等多媒体文件以及大文件，因为压缩效果不好，所以对于图片没有必要支压缩，如果想要优化，可以图片的生命周期设置长一点，让客户端来缓存。

开启Gzip功能后，Nginx服务器会根据配置的策略对发送的内容, 如css、js、xml、html等静态资源进行压缩,

使得这些内容大小减少，在用户接收到返回内容之前对其进行处理，以压缩后的数据展现给客户。

这样不仅可以节约大量的出口带宽，提高传输效率，还能提升用户快的感知体验, 一举两得;

尽管会消耗一定的cpu资源，但是为了给用户更好的体验还是值得的。

具体配置如下：

#开启gzip压缩功能

gzip on;

#允许压缩的页面最小字节数,如果文件小于10个字节,就不用压缩文件太小压缩无意义

gzip_min_length 10k;

#设置压缩缓冲区大小,此处设置为4个16K内存作为压缩结果流缓存

gzip_buffers 4 16k;

#压缩版本

gzip_http_version 1.1;

#设置压缩比率,最小为1,处理速度快,传输速度慢

#9为最大压缩比,处理速度慢,传输速度快

#级别越高,压缩就越小,节省了带宽资源,但同时也消耗CPU资源,折中为6

gzip_comp_level 6;

#进行压缩的文件类型

gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript;

3.Timeouts超时设置

#给客户端分配keep-alive链接超时时间,服务器将在这个超时时间过后关闭链接

#对于一些请求比较大的内部服务器通讯的场景,适当加大为120s或者300s,具体根据不同场景

keepalive_timeout 65;

#客户端向服务器发送一个完整的request header的超时时间。

#如果客户端在此时间内没有发送一个完整的request header

#那么Nginx返回HTTP 408错误（Request Timed Out）。它的默认值是60秒

client_header_timeout 30

#客户端与服务器建立连接后发送request body的超时时间。

#如果客户端在此时间内没有发送任何内容,那么Nginx返回HTTP 408错误(Request Timed Out)

#它的默认值是60秒

client_body_timeout 30;

#发送数据至客户端超时,默认60s,如果连续的60s内客户端没有收到1个字节,连接关闭

send_timeout 60

#发送请求给upstream服务器的超时时间,超时设置不是为了整个发送期间,而是在两次write操作期间

#如果超时后,upstream没有收到新的数据，nginx会关闭连接

proxy_send_timeout 300

4.Buffer缓解后端的负载

对于大部分使用代理的用户来说，最关心的事情之一就是增加一台服务器对性能的影响。

在大部分场景下，利用 Nginx 的 buffer（缓冲） 和 cache（缓存） 能力，可以大大地减轻负担。

没有 buffer（缓冲）数据将会直接从代理服务器传输到客户端。如果客户端的速度足够快（假设），你可以直接把 buffer（缓冲） 关掉，让数据尽可能快速地到达；

如果使用 buffer（缓冲），Nginx 将会临时存储后端 response（响应），然后慢慢把数据推送给客户端；

如果客户端很慢，Nginx 会提前关闭后端服务器的连接。它可以任意控制分发的节奏。

如果buffer太小，Nginx会不停的写一些临时文件，这样会导致磁盘不停的去读写，现在我们先了解设置buffer的一些相关参数：

#允许客户端请求的最大单个文件字节数,在32位系统上默认是8k，在64位系统上默认是16k。可以在http, server 和 location模块中指定

client_body_buffer_size 16K

#request header分配缓冲。默认的值是1k，可以在http 和 server模块中定义

#用于设置客户端请求的Header头缓冲区大小，大部分情况1KB大小足够

client_header_buffer_size:

#设置客户端能够上传的文件大小,默认为1m

#如果web服务器提供大文件上传的话,那么设置好这个很重要。

client_max_body_size 2m

#指定request header缓冲的数量和大小。只有当默认的缓冲不够用时，它才能被使用。

#当请求处理完成后或者连接进入keep-alive状态时,它被释放,可以在http 和 server模块中定义

large_client_header_buffers 4 8k;

5.日志

日志记录是管理和审核系统的重要工具。记录大量数据并存储大型日志会使系统资源紧张,

但我们建议仅在非常特定的情况下禁用日志记录或进行性能故障排除。

#关闭访问日志

access_log off;

#设置访问日志

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];

path 指定日志的存放位置。

format 指定日志的格式。默认使用预定义的combined。

buffer 用来指定日志写入时的缓存大小。默认是64k。

gzip 日志写入前先进行压缩。压缩率可以指定，从1到9数值越大压缩比越高，同时压缩的速度也越慢。默认是1。

flush 设置缓存的有效时间。如果超过flush指定的时间，缓存中的内容将被清空。

if 条件判断。如果指定的条件计算为0或空字符串，那么该请求不会写入日志

误日志主要记录客户端访问Nginx出错时的日志，格式不支持自定义。

通过错误日志，你可以得到系统某个服务或server的性能瓶颈等。因此将日志好好利用,你可以得到很多有价值的信息。

error_log path(存放路径) level(日志等级)

path含义同access_log，level表示日志等级，日志等级分为[ debug | info | notice | warn | error | crit ],

从左至右，日志详细程度逐级递减，即debug最详细，crit最少。

一般生产我们记录warn以上级别的就可以了

6.worker_processes工作进程配置

worker_processes 表示工作进程的数量,一般情况设置成CPU核的数量即可,一个cpu配置多于一个worker数,对Nginx而言没有任何益处,

另外不要忘了设置 worker_cpu_affinity,这个配置用于将worker process与指定cpu核绑定,

降低由于多CPU核切换造成的寄存器等现场重建带来的性能损耗。

worker_connections配置表示每个工作进程的并发连接数，默认设置为1024。

#实例配置

#工作进程数

worker_processes 1;

#四核配置

worker_cpu_affinity 0001 0010 0100 1000;

#每个工作进程的并发连接数

worker_connections 1024;

7.开启epoll

写在events部分,在Linux操作系统下,nginx默认使用epoll事件模型,得益于此,nginx在Linux操作系统下效率相当高。

同时Nginx在OpenBSD或FreeBSD操作系统上采用类似于epoll的高效事件模型kqueue。在操作系统不支持这些高效模型时才使用select。

#配置

events {

use epoll;

worker_connections 1024;

}