使用 NGINX 进行微程序缓存的好处（使用权资产）

使用 NGINX 进行微程序缓存的好处（使用权资产）

为什么要缓存内容？

缓存能够一举两得：通过更快地传递内容，缓存可以改善网站性能，同时减轻源服务器的负担。缓存的效率取决于内容的缓存度。这些内容可以存储多长时间，如何检查更新，相同的缓存内容可以发给多少用户？

两者中间是个有趣的待缓存对象：可能会无计划更换，但是并非针对每位用户（或者在客户端通过 JavaScript实现个性化）的动态内容。这类内容的生成代价很高，提供过时版本又会带来新的问题。

适合缓存的动态内容包括：

经常更新的新闻或博客网站的首页，每隔几秒就有新文章发布最近资讯 RSS持续整合（CI）或搭建平台的进度页面库存、进度或筹款计数彩票开奖结果日历数据在客户端呈现的个人化动态内容，例如利用 cookie 数据展示的广告内容或数据（“你好，你的名字”）

动态内容的微程序缓存

微程序缓存是一种缓存技术，将内容缓存1秒左右很短的时间。这意味着网站更新会延迟不到1秒钟，这在很多情况下是可以接受的。

这种短暂缓存能给网站性能带来可察觉的改观吗？来试试看！

测试应用程序

测试中，vmstat 显示造成瓶颈的原因是利用 PHP 生成页面的 CPU 消耗（在 cpu 范围的 us 一列，数值为96到98。）

root@nginx-server:/var/www/html## vmstat 3procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st10  0      0 136076  44944 585920    0    0     0     0  476 1665 96  4  0  0  010  0      0 140112  44952 585924    0    0     0     4  506 1773 98  2  0  0  010  0      0 136208  44952 585924    0    0     0     0  576 2057 97  3  0  0  0

这种设置本身就是问题——它限制了网站每秒钟处理请求的数量不能超过5个，很容易遭到 DOS攻击，而通过添加 CPU 来解决这个问题意味着每年的托管费用都要增加1000美元。

利用 NGINX 简化微程序缓存

利用 NGINX 来加速服务只需两步。

第一步： 通过 NGINX 代理服务器

在 WordPress 服务器安装 NGINX 或 NGINX Plus 并进行配置，让它接收访问流量并在内部转发到 WordPress 服务器：

NGINX 代理服务器配置比较简单：

笔者还修改了 Apache 配置（监听端口号和虚拟服务器），这样 Apache 就绑定到了 localhost:80。

你可能以为添加额外的代理服务器会对性能造成负面影响，但是实际上性能变化可以忽略不计：

第二步： 启动短期缓存

在服务器配置中只添加了两条指令，NGINX 或 NGINX Plus 就可以缓存所有可缓存的响应。带有 200 OK 状态码的响应只缓存1秒钟。

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {    proxy_cache cache;    proxy_cache_valid 200 1s;    ...}

笔者再次运行基准测试时，看到了性能显著提升：

笔者还从 NGINX Plus 的活动检测控制面板找到进一步的线索。测试前：

测试后：

控制面板报告显示，NGINX 在测试期间处理了18032条请求（ab 汇报的18022条请求，以及基准在30秒结束时突出的10条请求）。但是，NGINX 转发了150条请求到上游服务器，在缓存内容1秒钟的情况下，这比我们期望的30秒测试应有的请求数多得多。

怎么回事？为什么 CPU 使用率很高，缓存更新比预期数字更大？

这是因为每次缓存条目过期时，NGINX 就会停止使用它。NGINX 将所有请求都转发给上游 WordPress 服务器，直到它收到响应，可以用新内容来缓存。

这导致了 WordPress 服务器收到的请求经常激增到10条。这些请求会占用 CPU，比缓存响应的请求延迟更多，这就解释了测试结果中的高标准差。

用 NGINX 优化微程序缓存

笔者想要的策略很清晰：需要在确保缓存内容最新的情况下，尽可能少地向上游源服务器转发请求。在缓存内容不断更新的前提下，笔者愿意从缓存获取旧的（延后1到2秒）响应。要实现这一目标，需要添加两条指令：

加上之前已经添加的缓存指令，笔者得到如下服务器配置：

server {    proxy_cache one;    proxy_cache_lock on;    proxy_cache_valid 200 1s;    proxy_cache_use_stale updating;    ...}

基准测试结果的变化十分惊人。每秒钟的请求数量从600跳跃到接近2200：

CPU 使用率也低多了（注意 cpu 下面 id 一栏的空闲时间）：

root@nginx-server:/var/www/html# vmstat 3procs -----------memory---------- ---swap-- -----io---- -system--- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us sy id wa st 1  0      0 106512  53192 641116    0    0     0    37 11016 3727 19 45 36  0  0 1  0      0 105832  53192 641808    0    0     0    68 17116 3521 13 56 31  0  0 1  0      0 104624  53192 643132    0    0     0    64 14120 4487 15 51 33  0  0

数据传输率（121379.72千字节/秒，或121兆字节每秒）相当于0.97千兆，因此该测试受网络限制。CPU 平均使用率为66%，该服务器的峰值性能应该大概为2185/0.66 = 3300 个请求/秒。

另外，关注 ab 报告的连续响应时间（标准偏差只有8.1毫秒），以及操作面板显示的30秒测试中转发给上游服务器的请求数量很少（16）：

为什么只有16条请求？我们知道缓存到1秒钟时会清零，这个更新过程最多需要0.661秒（从 ab 结果来看），因此可以推测，更新频率不会快于每1.66秒一次。在30秒钟的时间之外，只会收到最多18（30/1.66）条请求。

了解更多

本文简单展示了在短时间内缓存动态内容可能带来的好处，以及 NGINX Plus 的活动监测数据在调整和诊断缓存配置时的用处。如果你想在生产环境中使用微程序缓存，笔者建议你创建并测试一个更为复杂的缓存规则，针对更长时间内的微程序缓存动态和静态内容。

要想了解更多信息，请查阅以下资源：