本博客 Nginx 配置之性能篇

标签: 博客 nginx 性能 | 发表时间:2015-05-27 13:02 | 作者:
出处:https://www.imququ.com

在介绍完我博客(imququ.com)的 Nginx 配置中 与安全有关的一些配置后,这篇文章继续介绍与性能有关的一些配置。WEB 性能优化是一个系统工程,涵盖很多方面,做好其中某个环节并不意味性能就能变好,但可以肯定地说,如果某个环节做得很糟糕,那么结果一定会变差。

首先说明下,本文提到的一些 Nginx 配置,需要较高版本 Linux 内核才支持。往往在实际生产环境中,升级服务器内核并不是一件容易的事。为了获得最好的性能,有些升级还是必须的。但往往服务器运维和项目开发并不在一个团队,一方追求稳定不出事故,另一方希望提升性能,本来就是矛盾的。好在我们折腾自己 VPS 时,可以无视这些限制。

TCP 优化

Nginx 关于 TCP 的优化基本都是修改系统内核提供的配置项,所以跟具体的 Linux 版本和系统配置有关,我对这一块还不是非常熟悉,这里只能简单介绍下:

  http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 60;
    ... ...
}

第一行的 sendfile 配置可以提高 Nginx 静态资源托管效率。sendfile 是一个系统调用,直接在内核空间完成文件发送,不需要先 read 再 write,没有上下文切换开销。

TCP_NOPUSH 是 FreeBSD 的一个 socket 选项,对应 Linux 的 TCP_CORK,Nginx 里统一用 tcp_nopush 来控制它,并且只有在启用了 sendfile 之后才生效。启用它之后,数据包会累计到一定大小之后才会发送,减小了额外开销,提高网络效率。

TCP_NODELAY 也是一个 socket 选项,启用后会禁用 Nagle 算法,尽快发送数据,可以节约 200ms。Nginx 只会针对处于 keep-alive 状态的 TCP 连接才会启用 tcp_nodelay

可以看到 TCP_NOPUSH 是要等数据包累积到一定大小才发送,TCP_NODELAY 是要尽快发送,二者相互矛盾。实际上,它们确实可以一起用,最终的效果是先填满包,再尽快发送。

关于这部分内容的更多介绍可以看这篇文章: NGINX OPTIMIZATION: UNDERSTANDING SENDFILE, TCP_NODELAY AND TCP_NOPUSH

配置最后一行用来指定服务端为每个 TCP 连接最多可以保持多长时间。Nginx 的默认值是 75 秒,有些浏览器最多只保持 60 秒,所以我统一设置为 60。

另外,还有一个 TCP 优化策略叫 TCP Fast Open(TFO),这里先介绍下,配置在后面贴出。TFO 的作用是用来优化 TCP 握手过程。客户端第一次建立连接还是要走三次握手,所不同的是客户端在第一个 SYN 会设置一个 Fast Open 标识,服务端会生成 Fast Open Cookie 并放在 SYN-ACK 里,然后客户端就可以把这个 Cookie 存起来供之后的 SYN 用。下面这个图形象地描述了这个过程:

tcp fast open

关于 TCP Fast Open 的更多信息,可以查看 RFC7413,或者这篇文章: Shaving your RTT with TCP Fast Open

开启 Gzip

我们在上线前,代码(JS、CSS 和 HTML)会做压缩,图片也会做压缩(PNGOUT、Pngcrush、JpegOptim、Gifsicle 等)。对于文本文件,在服务端发送响应之前进行 GZip 压缩也很重要,通常压缩后的文本大小会减小到原来的 1/4 - 1/3。下面是我的配置:

  http {
    gzip             on;
    gzip_vary        on;

    gzip_comp_level  6;
    gzip_buffers     16 8k;

    gzip_min_length  1000;
    gzip_proxied     any;
    gzip_disable     "msie6";

    gzip_types       text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
    ... ...
}

这部分内容比较简单,只有两个地方需要解释下:

gzip_vary 用来输出 Vary 响应头,用来解决某些缓存服务的一个问题,详情请看我之前的博客: HTTP 协议中 Vary 的一些研究

gzip_disable 指令接受一个正则表达式,当请求头中的 UserAgent 字段满足这个正则时,响应不会启用 GZip,这是为了解决在某些浏览器启用 GZip 带来的问题。特别地,指令值 msie6 等价于 MSIE [4-6]\.,但性能更好一些。另外,Nginx 0.8.11 后, msie6 并不会匹配 UA 包含 SV1 的 IE6(例如 Windows XP SP2 上的 IE6),因为这个版本的 IE6 已经修复了关于 GZip 的若干 Bug。

开启缓存

优化代码逻辑的极限是移除所有逻辑;优化请求的极限是不发送任何请求。这两点通过缓存都可以实现。

服务端

我的博客更新并不频繁,评论部分也早就换成了 Disqus,所以完全可以将页面静态化,这样就省掉了所有代码逻辑和数据库开销。实现静态化有很多种方案,我直接用的是 Nginx 的 proxy_cache:

  proxy_cache_path    /home/jerry/cache/nginx/proxy_cache_path levels=1:2 keys_zone=pnc:300m inactive=7d max_size=10g;
proxy_temp_path     /home/jerry/cache/nginx/proxy_temp_path;
proxy_cache_key     $host$uri$is_args$args;

server {
    location / {
        resolver                 127.0.0.1;  
        proxy_cache              pnc;
        proxy_cache_valid        200 304 2h;
        proxy_cache_lock         on;
        proxy_cache_lock_timeout 5s;
        proxy_cache_use_stale    updating error timeout invalid_header http_500 http_502;

        proxy_http_version       1.1;

        proxy_ignore_headers     Set-Cookie;
        ... ...
    }
    ... ...
}

首先,在配置最外层定义一个缓存目录,并指定名称(keys_zone)和其他属性,这样在配置 proxy_pass 时,就可以使用这个缓存了。这里我对状态值等于 200 和 304 的响应缓存了 2 小时。

默认情况下,如果响应头里有 Set-Cookie 字段,Nginx 并不会缓存这次响应,因为它认为这次响应的内容是因人而异的。我的博客中,这个 Set-Cookie 对于用户来说没有用,也不会影响输出内容,所以我通过配置 proxy_ignore_header 移除了它。

客户端

服务端在输出响应时,可以通过响应头输出一些与缓存有关的信息,从而达到少发或不发请求的目的。HTTP/1.1 的缓存机制稍微有点复杂,这里简单介绍下:

首先:服务端可以通过响应头里的 Last-Modified(最后修改时间) 或者 ETag(内容特征) 标记实体。浏览器会存下这些标记,并在下次请求时带上 If-Modified-Since: 上次 Last-Modified 的内容If-None-Match: 上次 ETag 的内容,询问服务端资源是否过期。如果服务端发现并没有过期,直接返回一个状态码为 304、正文为空的响应,告知浏览器使用本地缓存;如果资源有更新,服务端返回状态码 200、新的 Last-Modified、Etag 和正文。这个过程被称之为 HTTP 的协商缓存,通常也叫做弱缓存。

可以看到协商缓存并不会节省连接数,但是在缓存生效时,会大幅减小传输内容(304 响应没有正文,一般只有几百字节)。另外为什么有两个响应头都可以用来实现协商缓存呢?这是因为一开始用的 Last-Modified 有两个问题:1)只能精确到秒,1 秒内的多次变化反映不出来;2)时间采用绝对值,如果服务端 / 客户端时间不对都可能导致缓存失效。HTTP/1.1 并没有规定 ETag 的生成规则,而一般实现者都是对资源内容做摘要,能解决前面两个问题。

另外一种缓存机制是服务端通过响应头告诉浏览器,在什么时间之前(Expires)或在多长时间之内(Cache-Control: Max-age=xxx),不要再请求服务器了。这个机制我们通常称之为 HTTP 的强缓存。

一旦资源命中强缓存规则后,再次访问完全没有 HTTP 请求(Chrome 开发者工具的 Network 面板依然会显示请求,但是会注明 from cache;Firefox 的 firebug 也类似,会注明 BFCache),这会大幅提升性能。所以我们一般会对 CSS、JS、图片等资源使用强缓存,而入口文件(HTML)一般使用协商缓存或不缓存,这样可以通过修改入口文件中对强缓存资源的引入 URL 来达到即时更新的目的。

这里也解释下为什么有了 Expire,还要有 Cache-Control。也有两个原因:1)Cache-Control 功能更强大,对缓存的控制能力更强;2)Cache-Control 采用的 max-age 是相对时间,不受服务端 / 客户端时间不对的影响。

另外关于浏览器的刷新(F5 / cmd + r)和强刷(Ctrl + F5 / shift + cmd +r):普通刷新会使用协商缓存,忽略强缓存;强刷会忽略浏览器所有缓存(并且请求头会携带 Cache-Control:no-cache 和 Pragma:no-cache,用来通知所有中间节点忽略缓存)。只有从地址栏或收藏夹输入网址、点击链接等情况下,浏览器才会使用强缓存。

默认情况下,Nginx 对于静态资源都会输出 Last-Modified,而 ETagExpireCache-Control 则需要自己配置:

  location ~ ^/static/ {
    root      /home/jerry/www/blog/www;
    etag      on;
    expires   max;
}

expires 指令可以指定具体的 max-age,例如 10y 代表 10 年,如果指定为 max,最终输出的 Expires 会是 2037 年最后一天, Cache-Controlmax-age 会是 10 年(准确说是 3650 天,315360000 秒)。

使用 SPDY(HTTP/2)

我的博客之前多次讲到过 HTTP/2(SPDY),现阶段 Nginx 只支持 SPDY/3.1,这样配置就可以启用了(编译 Nginx 时需要加上 --with-http_spdy_module 和 --with-http_ssl_module):

  server {
    listen             443 ssl spdy fastopen=3;
    spdy_headers_comp  6;
    ... ...
}

那个 fastopen=3 用来开启前面介绍过的 TCP Fast Open 功能。3 代表最多只能有 3 个未经三次握手的 TCP 链接在排队。超过这个限制,服务端会退化到采用普通的 TCP 握手流程。这是为了减少资源耗尽攻击:TFO 可以在第一次 SYN 的时候发送 HTTP 请求,而服务端会校验 Fast Open Cookie(FOC),如果通过就开始处理请求。如果不加限制,恶意客户端可以利用合法的 FOC 发送大量请求耗光服务端资源。

HTTPS 优化

建立 HTTPS 连接本身就慢(多了获取证书、校验证书、TLS 握手等等步骤),如果没有优化好只能是慢上加慢。

  server {
    ssl_session_cache          shared:SSL:10m;
    ssl_session_timeout        10m;

    ssl_session_tickets        on;

    ssl_stapling               on;
    ssl_stapling_verify        on;
    resolver 8.8.4.4 8.8.8.8 valid=300s;
    resolver_timeout 10s;
    ... ...
}

我的这部分配置就两部分内容:TLS 会话恢复和 OCSP stapling。

TLS 会话恢复的目的是为了简化 TLS 握手,有两种方案:Session Cache 和 Session Ticket。他们都是将之前握手的 Session 存起来供后续连接使用,所不同是 Cache 存在服务端,占用服务端资源;Ticket 存在客户端,不占用服务端资源。另外目前主流浏览器都支持 Session Cache,而 Session Ticket 的支持度一般。

ssl_stapling 开始的四行用来配置 OCSP stapling 策略。浏览器可能会在建立 TLS 连接时在线验证证书有效性,从而阻塞 TLS 握手,拖慢整体速度。OCSP stapling 是一种优化措施,服务端通过它可以在证书链中封装证书颁发机构的 OCSP(Online Certificate Status Protocol)响应,从而让浏览器跳过在线查询。服务端获取 OCSP 一方面更快(因为服务端一般有更好的网络环境),另一方面可以更好地缓存。有关 OCSP stapling 的详细介绍,可以 看这里

好了,我的博客关于安全和性能两部分 Nginx 配置终于都写完了。实际上很多策略没办法严格区分是为了安全还是性能,比如 HSTS 和 CHACHA20_POLY1305,两方面都有考虑,所以写的时候比较纠结,早知道就合成一篇来写了。

本文链接: https://www.imququ.com/post/my-nginx-conf-for-wpo.html参与讨论

推荐: 领略前端技术 阅读奇舞周刊

相关 [博客 nginx 性能] 推荐:

本博客 Nginx 配置之性能篇

- - JerryQu 的小站
在介绍完我博客(imququ.com)的 Nginx 配置中 与安全有关的一些配置后,这篇文章继续介绍与性能有关的一些配置. WEB 性能优化是一个系统工程,涵盖很多方面,做好其中某个环节并不意味性能就能变好,但可以肯定地说,如果某个环节做得很糟糕,那么结果一定会变差. 首先说明下,本文提到的一些 Nginx 配置,需要较高版本 Linux 内核才支持.

Nginx性能优化

- - 博客 - 伯乐在线
Nginx作为一个非常流行和成熟的Web Server和Reserve Proxy Server,网上有大量的性能优化教程,但是不同的业务场景千差万别,什么配置是最适合自己的,需要大量的测试和实践以及不断的优化改进. 最近用户调用量突破百万大关之后,就遇到了一些问题,虽然不算太复杂,但也折腾了挺长时间才搞定,积累了不少经验.

Nginx配置性能优化

- - CSDN博客互联网推荐文章
大多数的Nginx安装指南告诉你如下基础知识——通过apt-get安装,修改这里或那里的几行配置,好了,你已经有了一个Web服务器了. 而且,在大多数情况下,一个常规安装的nginx对你的网站来说已经能很好地工作了. 然而,如果你真的想挤压出Nginx的性能,你必须更深入一些. 在本指南中,我将解释Nginx的那些设置可以微调,以优化处理大量客户端时的性能.

Nginx线程池性能提升9倍(Thread Pools in NGINX Boost Performance 9x!)

- - SegmentFault 最新的文章
五年级英语水平,端午家庭作业. Nginx以异步、事件驱动的方式处理连接. 传统的方式是每个请求新起一个进程或线程,Nginx没这样做,它通过非阻塞sockets、epoll、kqueue等高效手段,实现一个worker进程处理多个连接和请求. 一般情况下下是一个CPU内核对应一个worker进程,所以worker进程数量固定,并且不多,所以在任务切换上消耗的内存和CPU减少了.

Linux & Nginx 性能参数调优

- - Linux - 操作系统 - ITeye博客
主要针对linux 文件句柄以及网卡参数调优. 修改linux最大文件句柄数. 查看open files  参数. vi /etc/security/limits.conf 添加. 修改以后保存,注销当前用户,重新登录,执行ulimit -a ,ok ,参数生效了. use epoll; 使用epoll的I/O模型 如:.

根据硬件设备配置高性能的Nginx

- - CSDN博客研发管理推荐文章
       Nginx的高级配置会涉及硬件,如果配置不好,会直接让性能下降好多好多. 我这里总结一下,如何根据服务器的硬件设备来配置Nginx.       低访问量的网络,可以这样配置.      标准的网络访问量,可以这样设置.     高访问量的网络,可以这样设置.      具体的网络环境,根据需要设置,并且使用并发工具测试一下.

nginx cache静态化+tmpfs 高性能cdn方案

- - 开源软件 - ITeye博客
本文档主要分为3部分内容:. (1)       解决不同URL访问不同后端的nginx配置方法. (2)       Nginx cache和内存文件系统的配置方法. (3)       Proxy cache的详细配置内容. 2       匹配不同URL访问不同后端. 如果想通过访问不同类别URL分配到不同的后端通过nginx实现,首先举个例子,将需求场景进行描述:.

(转)剖析nginx等单线程服务器设计原理与性能优势

- - 博客园-Ruby's Louvre
nginx现在正在以光的速度蔓延开来,他以其稳定性和高性能等众多优点迅速扩大市场,大家都知道,nginx是以单线程为基础的,那么他怎么能在并发性上取得优势的呢. 会不会因为网络阻塞而导致主线程阻塞呢. 下面就相关问题作一些概念性的阐述. 那么既然多线程都会存在这样的问题单线程怎么会逃脱的调呢. 对于公网就更不用说了,网络等IO阻塞才是影响服务器的主要因素,是那块短了的板.

nginx cache静态化+tmpfs 高性能cdn方案 原创-胡志广

- - 开源软件 - ITeye博客
nginx cache静态化+tmpfs 高性能cdn方案 原创-胡志广. cachenginxproxy静态化. 本文档主要分为3部分内容:. (1)       解决不同URL访问不同后端的nginx配置方法. (2)       Nginx cache和内存文件系统的配置方法. (3)       Proxy cache的详细配置内容.

深入NGINX:我们如何设计它的性能和扩展性

- - 博客园_知识库
   英文原文: Inside NGINX: How We Designed for Performance & Scale.   为了更好地理解设计,你需要了解NGINX是如何工作的. NGINX之所以能在性能上如此优越,是由于其背后的设计. 许多web服务器和应用服务器使用简单的线程的(threaded)、或基于流程的(process-based)架构, NGINX则以一种复杂的事件驱动(event-driven)的架构脱颖而出,这种架构能支持现代硬件上成千上万的并发连接.