Windows性能计数器中HTTP Service URL Group\Bytes Received/sec和Bytes Sent/sec最真实反映Web吞吐量，需结合Get Requests/sec与Request Queue\Queue Length等4项指标建立动态基线监控。
windows 自带的性能计数器能直接反映 web 服务器真实吞吐能力，关键不是看 iis 管理器或任务管理器里的粗略值，而是抓取 http.sys 底层传输数据——它绕过应用层缓存和代理，体现网卡到内核协议栈的真实字节流动。
盯紧 HTTP 服务 URL 组下的收发速率
这是最贴近“Web 吞吐量”的指标：
- 计数器路径为
HTTP Service URL Group\Bytes Received/sec和HTTP Service URL Group\Bytes Sent/sec - 每个 URL 组对应一个注册的 HTTP 端点（如
<a href="https://www.php.cn/link/24ceee8be459529f6c45975a3b790c63">https://www.php.cn/link/24ceee8be459529f6c45975a3b790c63</a>或<a href="https://www.php.cn/link/87fd9dd52429b487a575115761e900a6">https://www.php.cn/link/87fd9dd52429b487a575115761e900a6</a>） - 实例名不是随便写的，需用
netsh http show servicestate查出实际 URL 组 ID（例如2），然后在 PerfMon 中选中该实例
区分“请求量”和“数据量”，两者都要看
-
HTTP Service\Get Requests/sec反映请求数密度，适合判断并发压力 -
HTTP Service URL Group\Bytes Sent/sec反映响应体大小总和，单位是字节/秒，可换算成 Mbps（除以 125,000） - 若 Get/sec 很高但 Bytes Sent/sec 很低，可能是大量轻量 API（如健康检查）；反之则说明返回大资源（静态文件、图片流等）
别漏掉请求队列瓶颈信号
吞吐上不去时，常因请求在内核队列积压：
- 添加
HTTP Service Request Queue\Queue Length - 若持续 > 5，说明 HTTP 请求排队等待处理，即使 CPU 和磁盘不忙，用户也会感知延迟
- 同时观察
HTTP Service Request Queue\Requests Rejected/sec，非零值代表已开始丢弃请求，必须干预
导出基线并设告警阈值才真正有用
实时图表只看当下，长期监控要落地：
- 在 PerfMon 中新建“数据收集器集”，添加上述 4 个核心计数器（收/发字节数、Get/sec、队列长度）
- 采样间隔设为 15 秒，日志格式选 CSV，便于 Excel 或 Zabbix 解析
- 建议设置动态基线：过去 7 天同时间段的 P95 值作为阈值，比固定值更抗业务波动
不复杂但容易忽略。
