到达率小于总服务率于是接口延迟就能满足要求——这个推论少了一大步。平均负载只能描述部分压力尾部还受服务时间分布、突发、批处理与调度影响。先分清模型边界经典无限等待队列中的稳态讨论与有限队列满后拒绝请求的系统不同。有限队列的长度被容量限制即使到达率超过服务能力也不会无限增长但拒绝和等待会增加。把“不会长到无限大”当作服务健康标准没有实际意义。图中 λ、μ 的时间单位必须一致1/μ表示单个服务台的平均服务时间。并行服务台同质、到达与服务过程的独立性都是需要验证的假设不是接入网关天然具备的属性。用有限队列看清守恒关系下面是离散时间教学模拟。每个服务台每步完成一项工作总在途容量为服务台数加等待位数它不是 M/M/c 仿真也没有生成 P99。def simulate(arrivals, servers2, waiting_slots3): outstanding accepted completed rejected 0 limit servers waiting_slots for incoming in arrivals: if type(incoming) is not int or incoming 0: raise ValueError(nonnegative arrival counts required) done min(servers, outstanding) completed done outstanding - done admitted min(incoming, limit - outstanding) accepted admitted rejected incoming - admitted outstanding admitted assert outstanding limit assert accepted completed outstanding assert sum(arrivals) accepted rejected return completed, outstanding, rejected finished, pending, dropped simulate([7] * 5) assert (finished, pending, dropped) (8, 5, 22) print({completed: finished, pending: pending, rejected: dropped})队列一直有界却拒绝了大量请求。若只看已完成请求的平均延迟甚至可能漏掉那些根本没进系统的请求。这也是性能报告必须同时写拒绝率、超时和客户端放弃的原因。让模型先接受真实分布的检验采集时区分排队等待、服务处理与端到端耗时。按照请求类型查看分布不用均值掩盖慢请求把短时突发、长尾服务时间和失败重试纳入回放。若希望估算稳态概率需要明确选择的队列模型与参数拟合方式。Kubernetes 的 Kueue 准入跟踪文章说明了另一个容易混淆的层次工作负载等待准入与 Pod 等待调度是不同阶段。测延迟时应从正确的排队阶段开始计时。本文只验证有限容量与计数守恒没有运行随机排队模型、集群或请求压测。排队论适合帮助提出容量问题要承诺 P99还得回到可复现的流量与目标环境。
