WP Super Cache 的 max-age 有问题
我厂做的是高性能网关,CDN 也是其中一大功能,所以就要吃自己的狗粮。之前多次尝试在七牛上配置全站 CDN,均以失败告终,这次因为是自家的产品,可以找同事咨询,所以打算再试一次。
配置过程暂且不提,基本上很顺利。结果在缓存上遇到一些麻烦,源站(也就是我的博客)控制为:max-age=3,所以基本上完全失效。
由于这个东西很多地方都可以控制,所以只好逐一排查。首先打开 WP Super Cache 的配置——它负责缓存,所以从它找起——无果;然后 Google “wordpress cache-control”,无结果;然后 Google “max-age=3”,发现这个地址:Cache-Control max-age=3, must-revalidate,原来缓存 max-age=3 竟然是插件的问题,而且一直保留至今。
按图索骥,打开 /wp-content/plugins/wp-super-cache/wp-cache-phase1.php,没有找到,原来这段已经被挪到 wp-cache-phase2.php,而且亦然没改……修改为 86400,缓存就可以 HIT 了。
至于这个地方是不是 Bug?我觉得是。这么短的时间不科学,如果真的这样,不如放出来给用户选择。
相关文章
TiDB 账单爆炸之后:一次跌宕起伏的降本排查,从 Cloudflare 边缘到数据库计费内核,降本$30/月
博客的 TiDB 账单逼近限额,RU 基线常年 110+。我用两天逐层排查:边缘缓存、漏洞扫描器、WordPress 对象缓存、连接税、TiFlash 副本、演示数据……一个接一个假设被数据打脸。把能
测试使用 Notion 作为编辑器发布博客
测试用 Notion 作为编辑器发布 WordPress 博客:博客重构成 headless 架构后的内容工作流探索,记录 Notion 同步方案的配置过程与遇到的问题。
记一次 TiDB Cloud Serverless 超额导致的博客超时故障
一次真实故障复盘:TiDB Cloud Serverless 免费额度用尽导致博客 502 超时。记录从发现问题、定位到 RU 超额、上调预算恢复服务的全过程,以及后续降低数据库用量的思路,供使用 S


