页面变快了，不一定代表缓存有效；源站请求减少，也可能是访问量下降。评估网站加速服务的日志分析与缓存效果评估，应把命中记录和回源记录放在同一时间范围内对照，并确认两类数据统计的是同一批请求。
例如，一个提供文档和图片的网站，用户访问首页时可能获取 HTML、CSS、JavaScript 和图片。图片与带版本号的静态文件通常适合缓存；包含个人信息的页面则可能需要绕过共享缓存。日志应帮助你看清每类请求实际发生了什么。
先辨认日志能说明什么
常见访问日志会记录时间、请求路径、状态码、响应字节数和处理耗时。Apache HTTP Server 的常见日志格式能提供部分字段，但缓存是否命中通常要看加速层另外记录的缓存状态、缓存键或回源耗时。只有源站访问日志时，看不到某个请求被边缘节点直接响应的完整情况。
- 命中：缓存层直接返回对象。关注命中次数、响应字节数和耗时。
- 回源请求：缓存层向源站取内容或重新验证。回源不必然是故障，首次访问、缓存过期和主动刷新都可能触发。
- 绕过或不可缓存：请求被规则排除，或响应条件不适合缓存。应检查对应路径和原因，而不是把它归为普通未命中。
状态码也不能单独证明缓存结果。200 可能来自缓存，也可能来自源站；304 表示条件请求下内容未变化，但是否减少了传输或源站负担，要结合缓存层记录和响应字节数判断。加速服务的缓存状态字段名称各异，解读前先核对日志字段说明。
用两个口径衡量缓存收益
请求命中率是命中请求数除以纳入统计的可缓存请求数。字节命中率则比较由缓存直接交付的字节数与可缓存响应的总字节数。前者回答“多少请求没回源”，后者回答“多少传输量由缓存承担”。小图标请求很多时，请求命中率可能很高，但大文件仍频繁回源；这时字节命中率更能揭示流量压力。
举例来说，某小时有 10,000 个可缓存请求，其中 7,000 个命中，请求命中率为 70%。若同一统计口径下，缓存交付 5.6 GB、可缓存响应总量为 8 GB，字节命中率也是 70%。这些数字只是计算示例，不代表行业基准。比较时应固定时间段、路径范围和过滤条件，并分别查看动态页面、静态资源及大文件。
按步骤定位回源原因
- 统一时间与范围。选取相同的小时或自然日，确认加速层和源站日志时区一致；剔除健康检查、内部探测等非用户流量时，记录过滤规则。
- 按路径分组。将图片、样式表、脚本、HTML 和接口请求分开统计。对带用户身份信息的请求，先确认缓存策略是否允许共享缓存。
- 检查缓存状态与回源耗时。筛出未命中、绕过、重新验证和回源失败记录，观察是否集中在特定路径、查询参数或状态码。相同文件因查询参数不同而产生多个缓存键，是常见的命中率下降原因。
- 对照源站日志。按时间、路径和可用的请求标识关联回源记录。若加速层回源上升而源站对应请求未同步增加，需先检查日志采样、重试和统计口径。
- 调整后复核。一次只改一类规则，例如静态文件缓存策略或查询参数处理；等待足以覆盖日常访问波动的观察时段，再比较命中率、回源字节数、源站耗时和错误率。
别把高命中率当成唯一目标
命中率升高但页面内容过期、个性化响应被错误共享，显然不是有效优化。相反，低命中率也可能是正常结果：资源刚发布、访问分散，或内容按用户身份变化时，缓存空间难以复用。评估网站加速服务的日志分析与缓存效果评估，还要检查缓存内容是否正确、回源是否稳定，以及用户实际请求的响应时间。
发现问题后，先判断它属于统计口径、缓存规则还是源站能力，再决定是否调整。把命中、回源和响应耗时放在同一张分组报表中，比只看一个百分比更容易找到原因。
常见问题
命中率多少才算合格？
没有适用于所有网站的固定门槛。资源类型、访问集中度和缓存策略不同，应与自身基线、回源负载及响应时间一起比较。
源站日志里没有命中记录，正常吗？
正常。被缓存层直接响应的请求通常不会到达源站。命中情况应从加速层日志或其统计报表获取。
缓存未命中一定要修复吗？
不一定。首次访问、个性化内容和需要重新验证的资源都可能合理回源。应先查看原因、路径和回源代价。
评估时最容易漏掉什么？
常见遗漏是统计范围不一致，以及只看请求命中率、不看字节命中率和源站响应情况。
