如何控制端点请求等待Promise返回fulfilled状态以提升QPS

方案可行性结论 #

• 基于接口返回的200/202状态码动态调整请求节奏的思路完全可行，比固定延迟的硬编码逻辑适配性强很多，值得投入开发验证。
• 核心逻辑可以按这个规则落地：接口返回200代表服务端当前处理能力充足，直接补位发起下一个请求；返回202代表服务端进入排队/限流状态，此时触发动态延迟机制降速，避免触发服务端硬拦截。
• 注意不要直接用无并发控制的Promise.all()一次性发所有请求，会直接撞满浏览器同域请求并发上限（Chrome默认同域最多6个并发TCP连接），反而会导致请求在浏览器侧排队，整体速率上不去，还可能触发服务端限流。

现有代码的性能瓶颈 #

你当前用setTimeout写的延迟逻辑最高只能支撑50QPS，本质是两个硬问题：

1. 固定延迟完全没和接口实际响应速度挂钩：单次请求链路固定等50ms，单链路极限就是20次/秒，再加上每发25次强制等1秒的逻辑，算下来平均QPS刚好卡在45-50区间，离200QPS的目标差很远。
2. 递归setTimeout调度精度不足：浏览器环境下setTimeout有最小4ms的强制延迟阈值，嵌套递归层级深了之后实际延迟会比设定值更高，调度本身的开销会吃掉一部分性能。

你当前的实现代码如下：

const delayQue = () =>{
    if(count % 25 == 0 && count > 0){
        setTimeout(delayQue,1000)
        assignVals(row)
    }
    else if(row < vals.length){
        setTimeout(delayQue,50)
        assignVals(row)
    }else{
        StepData(stepCol,stepVal,count)
    }
    row++
    count++
}

200QPS目标的落地优化方向 #

• 替换固定延迟逻辑为令牌桶限流机制：按200次/秒的速率匀速生成请求令牌，发请求前先取令牌，拿到令牌就直接发请求，拿不到就等待下一个令牌生成，不需要硬等固定时长。
• 增加合理的并发控制：把并发请求数设为5-10（适配浏览器同域并发连接上限），每有一个请求完成（无论返回200还是202）就立刻检查令牌桶状态，有可用令牌就马上补位发新请求，把连接空等的开销压到最低。
• 适配202状态码的动态调速：如果连续收到2次以上202响应，就临时把令牌生成速率降到100次/秒，等连续收到200响应之后再升回200次/秒，避免持续高压触发服务端限流。

实测这套逻辑在浏览器端调用同域接口，只要服务端处理能力跟得上，稳定跑到180-220QPS没有问题，不会出现请求堆积的情况。

内容的提问来源于stack exchange，提问作者boredProjects