米饭团

网站快不快，访客最先感知，搜索引擎也在乎。自建站的性能问题往往不是某一处代码慢，而是架构上没有缓存体系，每个请求都老老实实去查数据库。这篇分享一套我自己在用的性能优化方法：先分层缓存，再用压测验证。

一、缓存要分层，职责要单一

我的架构里缓存分三层：数据层负责把数据库查询结果缓存下来，展示层把整块渲染好的页面片段缓存下来，接口层再把外部调用的结果缓存住。分层的意义在于失效策略可以分开设计——文章更新时只需要刷掉相关展示块，不必清空整个站。缓存粒度过粗会导致「改一个字全站刷新」，粒度过细又会让键数量爆炸，按页面区块划粒度是实践里最平衡的选择。

缓存键的设计有两条铁律：一是键里必须包含所有影响输出的变量，比如分页页码，漏掉页码就会出现「第一页永远缓存」的经典事故；二是版本号机制，键名加版本后缀，模板改了就升版本，老缓存自然失效，比逐个清理可靠得多。

二、缓存引擎怎么选

小站用 SQLite 文件缓存绰绰有余，读写都在本地，零运维。流量上来后建议换成 LMDB 这类轻量级键值引擎，我给自己博客升级过一轮：底层从 SQLite 换成 LMDB，上层加一个统一的缓存刷新类统筹失效，冷页面的响应时间直接砍掉一个数量级。选型要点只有一个——缓存层绝不能反过来依赖数据库，否则数据库一抖，缓存层跟着挂，就失去了兜底的意义。

三、压测：用数据代替感觉

优化之前先压测，否则你不知道瓶颈在哪。方法很简单：用压测工具模拟递增并发，记录响应时间每秒请求数。我自己博客的实测数据是：单请求服务时间约六毫秒，对应每秒请求数天花板一百五左右，加并发也不再涨，这就说明瓶颈在单进程处理能力上。有了这组数，优化方向就清晰了——要么把单请求耗时压下去，要么把进程加起来，而不是凭感觉乱改。

四、一个提醒

性能优化的顺序应该是：先缓存、再数据库索引、最后才是代码微优化。九成的慢站问题靠前两步就解决了。而每做一次优化，都回到压测里验证一遍，让数据告诉你这次改动值不值。性能不是玄学，是工程。