最准的 QPS 分布判断方式是直接统计各 worker 进程处理的请求数；需在 Nginx 日志中添加 $pid 和 $msec，再用 awk、sort、uniq 按秒聚合分析。

直接看各 worker 进程处理了多少请求，是最准的 QPS 分布判断方式。Nginx 本身不暴露每个进程的实时 QPS，但可通过日志 + 进程 ID（$pid）做秒级归因，再结合统计工具快速算出分布。

在日志中记录进程 ID 和时间戳

修改 log_format，显式加入 $pid 和毫秒级时间 $msec：

log_format perf '$pid - $msec - [$time_local] "$request" $status $request_time';

重启 Nginx 后，每条访问日志开头就带进程号和精确到毫秒的时间点，为后续按秒聚合打下基础。

用 awk + sort + uniq 统计每秒各进程请求数

压测运行中（比如持续 60 秒），抽样分析最近 1 秒日志即可反映瞬时分布：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 提取最近 1 秒内的日志行（假设当前时间戳为 1726379800.123）：
  awk -v t=1726379800 '$2 >= t && $2
• 按进程 ID 统计请求数：
  awk -v t=1726379800 '$2 >= t && $2

输出类似：
 482 12345
 476 12346
 469 12347
说明三个 worker 进程在该秒内处理请求数相差不到 3%，属均匀分布。

配合 stub_status 实时观察连接状态分布

启用 ngx_http_stub_status_module（编译时默认包含），配置 location 如下：

location /nginx_status {
  stub_status;
  allow 127.0.0.1;
  deny all;
}

访问 curl http://localhost/nginx_status，输出如：

Active connections: 3245
server accepts handled requests
 1248567  1248567  2497134
Reading: 12 Writing: 42 Waiting: 3191

注意：这反映的是全局汇总值。要定位进程级差异，需搭配 ps 或 top -p 查看各 worker 的 CPU 占用是否同步均衡——若某进程 CPU 持续高于均值 20% 以上，而其日志请求数却偏低，说明它可能卡在等待后端或锁竞争上。

避免误判的两个关键点

• 别只看平均 QPS 总值：总 QPS 从 1 万升到 1.2 万，不代表负载更均衡；可能只是某个 worker 从 1500 跑到 3000，其余 7 个反而下降了
• 短时压测要避开启动抖动：前 2–3 秒常有 accept 队列填充、缓存预热等干扰，建议跳过首秒再采样