在高并发、高可用系统中，监控性能指标是保证用户体验与系统稳定性的核心环节。其中，QPS（Queries Per Second，或 Requests Per Second） 是最常被提及的指标之一。本文将分两部分来讲清楚什么是 QPS，它与其它指标的区别，以及在 IIS + .NET WebAPI 环境中如何统计 QPS。
什么是 QPS？它为何重要？
QPS 的定义
QPS 即 “每秒查询率”，是指系统在一秒钟内能够接受并响应的请求 (或查询) 的数量。
通常也写作 RPS（Requests Per Second），尤其在 Web 服务中，用来衡量请求的吞吐能力。
它反映系统在某一时刻的负载能力，是判断系统是否能承受当前 / 峰值流量的关键指标。
与 TPS、并发数、响应时间的区别与关系
TPS（Transactions Per Second）：通常指“业务事务”每秒处理的次数。一个事务可能包含多个子请求／调用，也可能包括数据库写入、外部依赖调用等。因此 TPS 往往比 QPS 更能反映业务完成度。
并发数（Concurrency）：指系统中同时处理请求的数量。即系统中处于 “正在处理” 状态的请求数。它与 QPS 和响应时间密切相关。
响应时间（RT 或 Latency）：一条请求从发出到响应所耗费的时间。如果响应时间变长，即使并发数高，QPS 也可能下降。
三者之间常见关系为：QPS ≈ 并发数 ÷ 平均响应时间
这一公式说明，在同等并发数的情况下，响应时间越低，系统能达到的 QPS 越高。反之响应时间若上升，系统的吞吐能力被拉低。
QPS 在 IIS / .NET WebAPI 环境中的统计方法
在 IIS + .NET WebAPI 上统计 QPS，通常可从多个维度与工具来实现。下面是常见的方法与实践步骤：
方法一：使用 Windows 性能计数器（Performance Counters）
Windows / IIS 提供很多性能计数器，可以实时或周期性地监控请求数／秒等指标。常见的相关计数器包括：
ASP.NET Applications / Requests/Sec：显示 ASP.NET 应用每秒处理的请求数。
Web Service / Get Requests/sec, Post Requests/sec 等（视具体版本与配置而定）：显示 IIS 层面对静态文件或特定 HTTP 方法的请求吞吐。
HTTP.sys + IIS Worker Process 请求队列、当前连接数等也能反映系统是否已经接近瓶颈。
查看步骤：
- 打开 “性能监视器”（Performance Monitor，也称 PerfMon）
- 添加相关计数器，如 ASP.NET 的 Requests/Sec。
- 设置监控频率（比如每秒、每五秒等）
- 在负载运行或模拟压力下观察该计数器的实时值与其变化趋势
- 优点是实时性强、开销小；缺点是仅能反映服务器内部视角／整体请求数，不太容易细分到某个接口／某个路由。
方法二：分析 IIS 日志
IIS 可以记录所有 HTTP 请求的日志（如 W3C 日志格式）。通过日志可以统计一段时间内的请求数，从而计算平均 QPS 或峰值 QPS。
实施步骤：
- 确认 IIS 日志已经启用，并包含时间戳字段、请求 URL、状态码等必要字段。
- 收集日志（例如每分钟／每小时一个日志文件）
- 使用脚本或日志分析工具（如 Log Parser、ELK / Splunk / Azure Monitor 等）统计在某个时间区间内的请求条数 / 秒。例如统计某一分钟内的请求数除以 60 得到该分钟内的平均 QPS。
- 若要得到峰值 QPS，可以选择 “某一分钟内请求数最高的那一分钟” 或者更细粒度（如某 10 秒或 5 秒区间）来计算。
这种方法的优点是允许细分某个路由、接口、客户端 IP 等维度；缺点是日志延迟 + 分析开销。
方法三：在 WebAPI 中插入中间件或代码统计
如果希望监控某些特定接口、路由或业务流程的 QPS，可以在 WebAPI 的中间件层插入自定义统计逻辑。
实施步骤示例：
- 创建一个中间件或过滤器（filter），在请求进入时记录时间戳，在响应出去后或异常时也记录。
- 在中间件中维护一个计数器／滑动窗口（sliding window）或环形缓冲区（circular buffer），例如记录过去 1 分钟、10 秒或 5 秒内每秒请求数。
- 定期把计数器值写入日志或暴露为监控指标（例如通过 Prometheus、Application Insights、InfluxDB 等）。
- 可细分到接口级别，例如把统计按 URL 路由分类或按 API 名称分类。
这种方式灵活，可为业务定制统计；缺点是要额外写代码并承担一些性能开销（尤其是在非常高 QPS 的场景中）。
方法四：结合外部监控 / APM 工具
很多现成的监控系统 / APM（Application Performance Monitoring）工具，支持 IIS/.NET 环境，能自动采集请求数、响应时间、错误率等，并可绘制 QPS 曲线。
例如：
- Azure Monitor / Application Insights
- New Relic
- Datadog
- Elastic APM
这些工具通常整合了性能计数器 + 日志 +代码级追踪，可以看到整体系统的 QPS 以及分接口 /按时间的峰值和平均趋势。
实践中的注意事项与优化建议
统计 QPS 时，做到准确可靠还需考虑以下因素：
- 监控时窗口（window）的选取：统计时间窗口太长会掩盖峰值，太短可能使数据波动太大。常用窗口有 1 秒、5 秒、1 分钟。
- 静态资源请求 vs 动态请求区分：静态文件（图片、CSS、JS 等）也算一个请求，但它们与业务逻辑请求对系统的压力不同。有时我们需要分开统计。
- 状态响应是否成功：如果很多请求导致了 5xx 或其他错误，这些也会被计入 QPS，但可能不希望视为“成功处理的业务请求”指标，需要根据需求过滤日志或计数器。
- 缓存 / CDN 层影响：在系统中如果使用了缓存（如静态资源缓存、页面缓存、CDN 等），实际到达 WebAPI 的请求数可能低于用户看到的请求数。监控要明确统计的是哪些层级的 QPS。
- 资源开销和性能影响：中间件代码统计、日志分析、实时计数器等都有一定性能开销，在极高负载下要设计好（异步写日志、避免锁、使用高效数据结构等）。
小结
QPS 是衡量系统在单位时间（通常是每秒）内处理请求能力的指标，是评价系统负载与吞吐能力的重要维度。它与 TPS、响应时间、并发数密切相关，但含义不同：TPS 更偏向业务完成次数。响应时间影响 QPS。并发数是系统压力的体现。
在 IIS + .NET WebAPI 环境中，可通过多种方式统计 QPS：Perf Counters、日志分析、自定义中间件、外部监控工具。合理组合这些方法可以获得准确、可监控、可预警的 QPS 指标。