ngx_http_xslt_module无内置监控指标，需通过响应头验证、日志调试、request_time差值分析、系统资源观测及错误日志捕获综合评估XSLT转换性能损耗与异常。
ngx_http_xslt_module 本身不提供内置监控指标，Nginx 官方也未暴露 XSLT 转换耗时、失败次数或内存占用等运行时性能数据。要评估它在处理静态 XML 转换时的性能损耗，需结合系统级观测、日志分析与间接指标进行综合判断。
确认模块是否实际参与转换
避免误判“损耗”，首先要验证 xslt_stylesheet 是否真正生效：
- 检查响应 Content-Type 是否匹配 xslt_types 所设值（如 text/xml、application/rss+xml），不匹配则跳过转换；
- 用 curl -I 请求目标路径，确认响应头中无 X-XSLT-Processed 类自定义标识（可手动添加用于调试）；
- 临时在 XSLT 文件开头插入
XSLT executed
通过访问日志估算转换开销
Nginx 日志变量 $request_time 记录了从读取请求头到发送完响应的总耗时，虽含网络与上游时间，但可用于横向对比：
- 配置两组 location：一组启用 xslt_stylesheet，另一组 proxy_pass 同一 XML 接口但禁用转换；
- 使用相同客户端、相同 XML 响应体（建议缓存后端响应，排除后端波动干扰）；
- 采集千次请求，用工具（如 awk + sort + head）统计 P95/P99 request_time 差值，差值即为 XSLT 转换的典型延迟增量；
- 若差值稳定在 1–5ms 内，说明轻量 XSLT（如简单 RSS→HTML）损耗可控；若超过 20ms 且 XML 不大，需检查 XSLT 是否含
监控系统资源变化
XSLT 处理由 libxslt 在 worker 进程内同步执行，会增加 CPU 占用与内存分配压力：
- 启用 nginx stub_status，关注 Active connections 和 Reading/Writing/Waiting 分布，XSLT 高负载时 Writing 值可能异常升高（因转换后需组装新响应体）；
- 用 pidstat -p $(pgrep nginx) -u -r 1 观察 worker 进程的 %CPU 与 %MEM 波动，对比开启/关闭 xslt_stylesheet 时的基线差异；
- 注意 libxslt 的内存管理特性：每次转换会申请临时缓冲区，若 XSLT 中使用
捕获转换异常与降级信号
性能损耗常伴随静默失败，需主动捕获：
- 将 error_log 级别设为 info 或 warn，关注 “xsltApplyStylesheet”、“xmlParseDoc”、“out of memory” 等关键词；
- 在 location 中添加 log_not_found off，避免因 XSLT 文件权限错误（如 Nginx 主进程无法读取 .xsl）导致大量 “open() failed” 日志刷屏；
- 设置 xslt_last_modified off（默认值），防止因原始 XML 的 Last-Modified 与转换后内容不一致触发下游缓存校验失败，造成重复转换。
