Swoole中Server->stats统计信息的区别

Server->stats() 返回的是分层、分角色、有时效性的快照值，字段对应不同层级（Reactor/Worker/Task）和生命周期（进程级/全局级），混用易致监控失真。

stats统计信息的区别">

Server->stats() 返回的不是“单一维度的统计”，而是一组分层、分角色、有时效性的快照值。不同字段反映的是不同层级（Reactor / Worker / Task）或不同生命周期（进程级 / 全局级）的状态，混用或误读会导致监控失真。

connection_num、accept_count、close_count 这三个连接数为什么对不上

它们统计口径完全不同：connection_num 是当前 活跃 TCP 连接数（Reactor 层维护），accept_count 是自服务器启动以来 成功 accept() 的总次数，close_count 是 已触发 close() 或超时断开的总次数。三者关系不是数学等式，而是状态流：

• accept_count 增长快但 connection_num 不涨？可能是连接建立后立刻断开（客户端异常、SSL 握手失败、协议头错误）
• accept_count - close_count 持续增大且 connection_num 不匹配？大概率存在连接泄漏（比如 onReceive 里没调 $server->close()，或协程未正确结束）
• connection_num 长期接近 max_connection？不是看差值，要看 accept_count 是否还在增长 —— 如果已停滞，说明新连接被内核拒绝（ulimit -n 不足或防火墙拦截）

worker_request_count 和 request_count 的适用场景差异

这两个计数器常被当成“QPS”，但实际语义和重置时机完全不同：

• request_count 是整个 Server 收到的 所有协议层请求总数（HTTP 的每个 request、TCP 的每个包、UDP 的每个 packet，只要触发了 onReceive/onRequest/onPacket 就计 1），在 主进程生命周期内累加，不重置
• worker_request_count 是当前 Worker 进程自启动以来处理的请求数，Worker 重启后归零；它才是判断单个 Worker 是否过载的依据（比如配合 max_request 触发优雅重启）
• 如果你用 worker_request_count 做全局 QPS 估算，会因 Worker 频繁重启导致跳变；想算真实 QPS，应该用 request_count 做时间窗口差值（自己补时间戳）

tasking_num、task_queue_num、task_push_count 容易混淆的边界

Task 相关字段描述的是三个不同阶段的任务状态，不能直接相加或比较大小：

• tasking_num：当前有 多少个 task 正在被 task_worker 执行中（即已 pop 出队列、正在跑回调）
• task_queue_num：当前 等待被 pop 的任务数量（内存队列长度），超过阈值说明消费者（task_worker）跟不上生产者（task() 调用）
• task_push_count：自服务启动以来 成功 push 到队列的任务总数，它包含已被 pop、正在执行、还在排队的所有任务；如果 task_push_count - task_pop_count > task_queue_num，说明有任务被丢弃（比如队列满且设置了 task_enable_coroutine=false 且无回调）

stats() 返回值没有时间戳，也不能跨进程聚合

Server->stats() 是一个轻量快照，返回的全是整型数值，不带任何上下文信息：

• 它不记录采集时间，你要自己用 time() 补；否则无法做速率计算（如每秒新建连接数）
• 它只反映调用时刻本 Worker 进程看到的状态 —— 在多 Worker 场景下，worker_request_count、tasking_num 等字段在每个 Worker 里都是独立值，不能简单求和；想汇总全局，必须从 Manager 进程或外部 HTTP 接口统一拉取各 Worker 的 stats 后合并
• 字段是否出现取决于编译选项和运行时配置：比如没启用 task 功能，tasking_num 就不会返回；没开启 SSL，ssl_accept_count 也不会有