平滑升级 nginx 使之支持 HTTP2

1. 得到 HTTPS 证书

本站用的是在 StartSSL.COM 申请的免费证书。请用 PC 浏览器访问,只支持根域名和一个二级域名。WoSign 的免费 SSL 证书也不错,全中文,不用翻墙,还支持多个域名。

不介意 Windows XP 用户无法建立 HTTPS 连接的请参考 Let’s Encrypt,免费好用的 HTTPS 证书 :支持多个域名、高大上的自动化部署。

2. 平滑升级 nginx

所谓平滑升级,保持网站可以访问的情况下,只为新开启的连接采用新的 nginx 服务,参考 nginx 平滑升级的详细操作方法

继续阅读平滑升级 nginx 使之支持 HTTP2

如何用 nginx 配置 gzip 和长缓存

这是一篇笔记,记录博主实际配置一个老生常谈的问题的过程。

Gzip 可以使资源加载时,大小缩减到原来的 1/3 。长时间缓存可以让浏览器不加载没有变化的文件。这两者都是前端性能优化的范畴,大家都懂的。

 

资源文件长缓存

将 Cache-Control 改为 public ,并加上一年的长缓存,配合 MD5 版本号实现长缓存 + 按版本号自动更新:

location /res{
    expires      1y;
    add_header   Cache-Control public;
}

为保证缓存效果,先去掉 Etag (Entity Tag)

浏览器会根据 Entity Tag 判断文件是否被修改过。而观星台用的是多台服务器。由于不同的服务器可能对同一个文件生成不同的 Entity Tag,用户第一次从服务器 A 拿过的文件,第二次从服务器 B 拿时,服务器给出的 Entity Tag 有可能不同。这就会造成重复下载,缓存形同虚设。由于已经有 MD5 插件机制起到了类似 Entity Tag 的效果,所以暂时先禁用掉 Entity Tag。

http{
    etag   off;
}

开启 Gzip 压缩

  1. 设置最小 1kb 开启 gzip 压缩;
  2. 开启 gzip_vary ,当用户使用代理服务器的时候,代理服务器会缓存压缩前后两个版本的文件,方便不同浏览器支持情况的用户;
  3. 将 gzip_http_version 设为 1.0,表明为 HTTP/1.0 以上的协议启用 gzip 压缩;
  4. 开启 js 、 css 、 xml 和 txt 文件的 gzip 压缩。其中网络图片(png/jpeg/gif)格式本身的压缩率一般都已经够高,不用再加 gzip 压缩,没什么效果还占用资源。对于观星台某些过大的 jpeg 图片,可以选择自动加 gzip 压缩作为折衷方案。但最主要的还是在做图的时候就设置好质量压缩比最高的压缩程度。
  5. 压缩比例设为 3。最小是 1 ,最大是 10。一般都设为 3。
  6. 对 IE1-6 不启用压缩,因为对 gzip 压缩支持的不太好,可能会出现闪跳问题(当然我们几乎没有这个类型的访客,可加可不加)。
  7. 其它未提到的设置保持默认。
http{
    gzip        on;
    gzip_min_length 1k;
    gzip_vary       on;
    gzip_http_version   1.0;
    gzip_types      text/plain application/x-javascript text/css application/xml image/jpeg;
    gzip_comp_level 3;
    gzip_disable    "MSIE [1-6].";
}

[翻译]修复 Nginx 和 PHP-FPM 之间的超时问题

本文是 《Fixing timeout between Nginx and PHP-FPM》 的译文。

=======译文开始========

若你使用 Nginx 作为 PHP-FPM 的反向代理,且你的 PHP 脚本很复杂或者很慢,需要运行很久,很可能就会看到 504 gateway time-out 错误。这是个很常见的错误,但是大多数情况下人们会找错解决问题的地方,他们不知道怎么找到哪个超时 directive 是正确的、符合他们的情景的。

原文配图:花五小时修复超时程序,不如用一个 directive 立即解决
原文配图:花五小时修复超时程序,不如用一个 directive 立即解决

我看见很多人拼命的试验 proxy_read_timeout, send_timeout, 甚至 client_header_timeout 和client_body_timeout 的 directive,但如果他们瞥一眼 Nginx 的 error_log,会看到一条类似这样的错误:

2013/01/19 11:36:59 [error] 14564#0: *1215 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 123.456.789.123, server: example.com, request: "POST /path/to/some/script.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com", referrer: "http://example.com/"

这条错误清楚的陈述了 Nginx 和 upstream 服务之间的连接超时这件事。在此这个 upstream 服务是 PHP-FPM,但也可以是任何 FastCGI 服务在读响应头时出错。若你据此稍加分析,就不会没找到 fastcgi_read_timeout 这个 directive。浏览文档,看看它是做什么:

设置 upstream 等待 FastCGI 进程发送数据的时长的 directive 。若你有长时间运行、若非结束不输出结果的 FastCGI 进程,修改这个 directive。若你在错误日志中看到 upstream 超时错误,那么增加这个参数到某个更合适的值。

所以,在 http, server 或者 location 的 { 和 } 之间加上这个 directive 并赋予足够高的数值是明智之举,例如:

location ~* .php$ {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_read_timeout 120;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

=======译文结束=======

看到这篇文章是因为 www.yymwz.com 国庆期间莫名其妙 504 gateway time-out 了四天,还顺带连累了同一个服务器上的本站一起 504 了。重启服务什么的都不行。搜索了下,叫我用什么 directive 的都有,而且都号称能解决问题,当然总不见效。最后还是按照这篇文章得到解决。修改了 fastcgi_read_timeout 的 directive 以后,mysql 被拖垮了一次,重启后就正常了,昨天那么久只挂了两次,已经好多了。

不过为什么 PHP 脚本会突然超时,博主我依然是百思不得其解的说。待后续吧。