apache响应延迟不能只看%d，它仅反映自身处理耗时，不包含网络传输、tcp建连及后端等待；需结合mod_status实时状态、多字段日志（%{msec}t/%d/%t）、压测工具与tcp层抓包分层定位用户感知延迟。
Apache 响应延迟不能只看日志里的 %D（处理时间），它只反映 Apache 自身执行耗时，不包含网络传输、TCP 建连、后端等待等环节。真正要追踪“用户感知的响应延迟”，需分层观测、轻量介入、快速定位。
用 mod_status 实时看请求排队与处理状态
这是 Apache 自带、零依赖、开箱即用的轻量监控入口。启用后可直观看到每个 worker 的实时状态（W：发送响应中，K：保持连接，. ：空闲），以及关键指标：
- ReqPerSec：当前每秒请求数，突降可能意味着后端阻塞或连接耗尽
- BytesPerSec / BytesPerReq：若字节数骤增但 ReqPerSec 下降，可能是大文件响应拖慢整体吞吐
- TimePerReq（平均）与 Max（最大）：若 Max 远高于平均（如平均 80ms，Max 2500ms），说明存在偶发长尾请求，需结合日志查具体 URI
用自定义日志格式暴露真实延迟链路
在 LogFormat 中加入多段耗时字段，把一次请求拆解为可归因的环节：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{msec}t %D %T" combined-latency
- %{msec}t：请求到达 Apache 时间戳（毫秒级），用于比对前后时间差
- %D：Apache 内部处理耗时（微秒），PHP/SSI/模块执行时间
- %T：总耗时（秒，精度 1/1000），含网络接收、解析、响应写出全过程
例如某条日志：... 172.16.1.5 - - [12/Jun/2026:23:40:12 +0000] "GET /api/user HTTP/1.1" 200 324 "-" "curl" 1718245212123 482932 0.512，说明网络+Apache 处理共耗时 512ms，其中 Apache 自身占了 483ms —— 问题大概率在 PHP 或数据库层。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
用 ab 或 wrk 做定向压测验证延迟变化
不靠猜测，用工具复现并量化。轻量、单机、无需部署：
-
ab（Apache Bench）：适合简单 GET/POST 验证 baseline
ab -n 200 -c 20 -H "Accept: application/json" https://example.com/api/status -
wrk：支持 Lua 脚本模拟真实行为，更贴近生产
wrk -t4 -c100 -d10s --latency -s auth.lua https://example.com/api/profile（auth.lua 可注入 token）
重点关注输出中的 Latency Distribution（尤其 90% 和 99% 分位），比平均值更能暴露长尾问题；若并发提升后 99% 延迟陡增，说明资源（如 MySQL 连接池、PHP-FPM 子进程）已成瓶颈。
用 ss 或 tcpdump 快速排查 TCP 层异常
当 %T 明显大于 %D（比如 %T=1200ms，%D=80ms），说明延迟不在 Apache 内部，而在网络或客户端侧：
-
ss -i sport = :80：查看当前所有 HTTP 连接的内核统计，重点看
retrans（重传次数）和rto（重传超时） - tcpdump -i any port 80 -c 100 -w /tmp/http.pcap：抓包后用 Wireshark 打开 → Statistics → TCP Stream Graphs → Round Trip Time Graph，直接看到 RTT 波动
- 若发现大量重传或 RTT >200ms，问题不在 Apache，而在中间网络、客户端设备或 TLS 握手环节
