mod_cache_socache单独启用对高频请求几乎没用，因为它不缓存响应体，只缓存URL对应的ETag、Last-Modified等元数据；若未配合mod_cache_disk主缓存且未关闭CacheQuickHandler，所有请求仍需读磁盘或回源，无法缓解I/O瓶颈。
mod_cache_socache 本身不缓存响应体，只缓存元数据；它对瞬时高频请求的优化效果，取决于你是否已用 mod_cache_disk 做主缓存，且是否正确关闭了 CacheQuickHandler。
为什么 mod_cache_socache 单独启用对高频请求几乎没用
它不存响应内容，只存 URL 对应的 ETag、Last-Modified、过期时间等“缓存索引”。当 1000 QPS 同时打来，每个请求仍需读磁盘取响应体——mod_cache_socache 只能帮你省下“要不要回源”那一次元数据比对开销（几微秒），而真正耗时的是磁盘 I/O 或后端调用。
- 如果你没配
CacheEnable disk，mod_cache_socache就像给空仓库装了个高速门禁系统——门再快，里面没货 - 它不解决并发读磁盘锁争用问题；高并发下
mod_cache_disk的文件锁仍是瓶颈，mod_cache_socache只是让锁竞争前多了一层快速判定 - 重启 Apache 后所有元数据丢失，瞬时高峰来临时又要重建索引，首波请求全 MISS
必须显式关闭 CacheQuickHandler 才能让缓存生效
Apache 默认开启 CacheQuickHandler on，导致绝大多数请求在进入主处理流程前就被 quick handler 截走，绕过 mod_cache 全部逻辑——mod_cache_socache 自然也完全不触发。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 必须在全局或虚拟主机配置中加：
CacheQuickHandler off - 这个指令不能放在
- 不关它，哪怕你把
CacheSocache配得再完美，日志里也看不到X-Cache: HIT
高频场景下 CacheSocache 和 CacheIgnoreHeaders 的关键组合
瞬时请求往往带大量重复 Cookie、Authorization 或 User-Agent，若不干预，mod_cache 会为每个变体生成独立缓存键，导致缓存碎片化、命中率暴跌。
-
CacheIgnoreHeaders Set-Cookie：防止含 Cookie 的请求污染共享缓存（除非你真要做用户级缓存） -
CacheIgnoreHeaders Authorization：适用于 API 网关层统一鉴权后转发的场景 -
CacheIgnoreHeaders User-Agent：对纯 JSON 接口安全；但若后端实际按 UA 返回不同格式（如 mobile vs desktop HTML），就不能忽略 -
CacheSocache shmcb:/var/cache/apache2/socache-cache(512000)：512KB 足够支撑约 2000 个活跃 URL 的元数据，别盲目调大
调试时盯死 X-Cache 和日志中的 cache-status
mod_cache 不报错、不警告、不写 success 日志，静默失败是常态。唯一可信信号是响应头：
- 发两次相同请求，用
curl -I看第二响应是否有X-Cache: HIT - 若只有
X-Cache: MISS，先确认CacheQuickHandler off是否生效；再检查后端响应头是否含Cache-Control: public, max-age=60 - 启用
CacheIgnoreCacheControl Off，否则即使后端写了max-age，Apache 也会无视 - 高频压测时，
mod_cache_socache的价值不在单次加速，而在降低mod_cache_disk的元数据查找抖动——这点容易被忽略
