标签： 性能优化
-
在 Go Learning & Documentation v2 的性能优化过程中，我曾把一条只读规划路径从约 164.03s 优化到 125.65s，后来又通过更激进的方案一度压到约 35.93s。但最终，更快的方案并没有被保留，因为对应的 correctness、freshness、stale detection 和 targeted tests 无法完整证明继续成立。本文整理这次性能优化过程，讨论为什么性能任务不能只看 benchmark，为什么 invocation-local reuse 通常比复杂 persistent cache、LRU 和多级 memoization 更适合这类强调 currentness 的工作流，以及什么时候应该停止继续优化。核心结论是：性能优化的目标不是把执行时间压到最低，而是在正确性、复杂度、验证成本和实际收益之间找到合理边界。
-
Go Learning & Documentation v2 为了支持更精确的 Semantic Compatibility，引入了更复杂的状态准备与影响范围判断，但也让部分 CLI 从秒级逐渐退化到分钟级。本文记录一次实际性能优化：通过识别同一 invocation 中被反复构建的 Compatibility State，将执行方式调整为 Prepare Once / Reuse Many Times，在不改变原有判断结果、fail-closed 语义和验证范围的前提下，将一次典型命令从 6m54.554s 优化到 10.335s，约提升 40.1 倍。
-
在 Go 多语言翻译项目从 A Tour of Go 扩展到 Site、Learn、Docs 及 future content packages 后，原本用于避免无意义重复审核的 glossary compatibility 机制开始暴露出严重性能问题：部分 Quality Check、Reviewer Bundle、finalization 与 revision 命令需要数分钟才能完成。本文记录一次真实的架构决策过程，对比“继续优化 semantic-delta compatibility carry”和“退回 glossary SHA 变化即 full QC”两种方案，并说明为什么最终暂时保留 compatibility、采用全语言共享的 invocation-local prepared-state 优化。同时进一步确定，无论最终采用哪一种方案，提前基于更完整的 Go/go.dev 技术语境稳定 glossary，都是降低长期维护成本的关键。
-
W3 Total Cache 的 Page Cache 明明设置了 4 天生命周期，实际缓存却长期活不过一天。经过对缓存文件、*_old ctime、WordPress Hook 和调用栈的持续追踪，最终确认了两条提前触发全量缓存失效的真实路径：Polylang 标签与翻译关系更新触发 edited_term / delete_term，以及 Yoast SEO 的 wpseo_detect_default_seo_data 每日 Cron 通过 WPSEO_Utils::clear_cache() 调用 w3tc_flush_posts()。本文记录两条根因的定位、独立 MU Plugin 修复、真实双语文章发布流程验证，以及修复后 Page Cache 首次存活超过 24 小时的结果，同时保留 Yoast option 实际变化场景尚待进一步验证的部分。
-
此前已经发现 W3 Total Cache 页面缓存长期很难看到超过 2 天的文件，但当时正在批量处理历史文章，不适合立即判断。等历史处理结束后，借这次 CPU 告警继续排查，最终发现联合预热 Sitemap 长期生成失败，根因是 Yoast SEO 生成 post-sitemap.xml 时触发 PHP 256M 内存耗尽并返回 HTTP 500。将 PHP-FPM memory_limit 提升到 512M 后，中英文 Sitemap 恢复 200，联合预热 Sitemap 也恢复自动更新。
-
一次阿里云 ECS CPU 接近 100% 的告警，最终从 Nginx 499、PHP-FPM max_children、Slowlog、W3 Total Cache Object Cache 和 Redis 一路排查到 Page Cache 冷缓存。实测发现服务器仅有 1 vCPU，而 /page/9/ 在 Cold MISS 时 TTFB 高达 10.6 秒，缓存命中后仅约 0.016 秒。最终没有提高 PHP-FPM 并发、关闭 Redis 或开启缓存预热，而是将 W3TC Page Cache 最长生命周期从 1 小时延长到 12 小时，以降低历史页面反复动态生成带来的 CPU 压力。
-
本文记录了在 Cloudflare 平台配置 SSL/TLS 加密模式与 Cache Rules 缓存规则的实战过程。文章首先建议将加密模式调整为完全（严格）模式以确保源站安全，随后详细展示了针对 WordPress 的 5 条核心缓存规则设置，包括绕过后台与 API 请求、强制缓存静态资源等。该方案有效实现了静态资源加速与动态内容隔离，保障了站点功能的稳定性与安全性。
-
针对 Ubuntu 26.04 桌面出现的 Firefox 卡顿和 OOM 问题，本文记录了从内存调度与应用负载两方面进行的性能调优过程。通过构建 RAM 与 ZRAM 的三层内存体系、降低 swappiness 值、限制 Firefox 多进程及开启 Clash Verge 轻量模式，有效降低了内存峰值与 Electron 应用负载。优化后系统运行稳定流畅，解决了日常并发场景下的卡顿与崩溃风险。
-
针对 Ubuntu 环境下 Clash Verge 内存占用过高导致系统卡顿的问题，本文记录了通过降低日志等级、关闭流量统计界面及冗余网络功能，并最终启用轻量模式的优化过程。经实测，该方案将后台常驻内存从 500MB 以上降至 200MB 左右，有效提升了桌面系统的稳定性，适用于需长期运行代理服务的 GNOME 桌面用户。