很多人觉得任务跑得慢就是地址不够，于是不断加地址、加并发，加到一定程度却发现速度纹丝不动，甚至还更慢了。问题在于并发不是凭空生效的——请求在到达目标站之前，要在好几个地方排队，只要其中一处堵住，前面加多少条地址都只是堆在门口等着。
并发数和连接数是一回事吗
不是。并发指的是同一时刻正在处理的请求数量，连接指的是承载这些请求的通道数量。一条连接上可以同时跑多个请求，也可以一次只跑一个，取决于协议和使用方式。所以”并发开到一百”并不等于”开了一百条连接”，更不等于”用了一百条地址”。三者是三回事，混着看就容易加错地方。
为什么加了地址速度还是没变
因为瓶颈通常不在地址数量上。如果客户端程序的连接池上限是十，那么无论你准备多少条地址，同时出去的永远只有十个请求；如果代理侧的队列有排队限制，多出来的请求会等在那里；如果目标站对单个来源的并发有上限，加多少地址都改变不了对方的规则。地址数量只在”每地址并发已满”这个前提下才成为瓶颈，而这个前提往往不成立。
先看连接池上限：客户端能同时维持多少条连接，决定了并发的天花板，这一步没放开，后面加什么都白搭。
再看代理侧队列：请求在代理这里可能被排队、限速或按优先级调度，队列满时新的请求只能等待，表现出来就是延迟整体变长。
最后才轮到地址数：只有当每条地址上的并发都已经接近上限，增加地址才会带来线性提升，否则收益有限，反而增加轮换带来的连接重建开销。
排队具体发生在哪几处
大致有三处。第一处是客户端，连接池大小、请求队列长度、是否开启多路复用，都在这里起作用。第二处是代理侧，接入层的并发限制、按使用者的配额调度、出口的带宽分配，请求会在这里等待资源。第三处是目标站，它对单个来源的并发连接数、单位时间请求数都有自己的安排。三处是串联关系，最窄的那一处决定整体速度。
需要注意的是，排队带来的延迟和地址质量差是两回事。排队的表现是整体均匀变慢、延迟随并发增加而上升；地址有问题的表现是部分请求失败、成功率下降。判断错了就会朝错误方向优化，把排队问题当成地址问题去换地址，成功率不会有任何改善。
- 先摸清三处上限：客户端连接池、代理侧配额、目标站限制，逐个确认
- 找出最窄那一处：串联结构里，最窄的环节决定整体速度
- 加地址前先看单址并发：单条地址还没跑满时，加地址的收益很小
- 并发与连接分开调：调的是连接上限还是同时请求数，先想清楚
- 用延迟变化判断：延迟随并发线性上升，八成是排队而不是地址问题
- 留出余量别压满：把并发压到上限运行，一旦波动就会大量失败
把这三条排队路径理顺之后，代理IP的扩量才真正有效：先放开客户端连接池，再确认代理侧的配额与队列，最后按单址并发的饱和程度决定要不要加地址——顺序对了，同样的资源能跑出明显不同的吞吐，也不会因为盲目加地址而多付成本。