并发上不去，通常不是本地程序不够快，而是链路中间那一环的处理能力有上限。代理IP的池化机制决定了并发能力的来源：出口数量、单出口的承载、以及调度开销。三者任何一个到顶，整体并发就上不去了。
三个上限来源
出口数量是第一个上限，池子小则可用并发有限；单出口的承载是第二个，任何单个出口都有它的处理极限；调度开销是第三个，并发越高，选择与切换出口的成本越大。代理IP的压力测试，应该分别测这三个，而不是只测一个总数。
三个都测，才知道卡在哪。
扩容该怎么排序
排序原则是先确认瓶颈再扩容。调度开销先到顶，扩出口数量没有意义，要先优化调度；单出口先到顶，扩池子也无效，要先确认是不是所有请求都挤在少数出口上。代理IP的容量规划，顺序错了就是白花钱。
需要注意的是，并发数字要在相同任务条件下测，任务类型变了结论也会变。
本地程序也会成为瓶颈
上限还有一个容易被忽略的来源：本地程序的并发模型。程序如果采用同步等待的方式，无论出口有多少，实际并发都上不去。判断办法是看程序在等待响应期间能否发起下一个请求，不能就说明瓶颈在本地，而不是在代理IP这一侧。
还有一点容易被忽略：并发上限不是固定值，它会随着目标端的响应速度变化。目标端变慢，请求占用连接的时间变长，同样的出口数量能支撑的并发就下降。代理IP的容量评估，需要把目标端状态作为前提条件写清楚。
所以谈并发时，先说明测的是什么任务、目标端什么状态、持续多长时间。三个条件写清楚，代理IP的并发数字才有意义，也才能在换环境时判断原来的结论还成不成立。
条件不同，数字不可比。
并发问题八成不是能力不够，而是分布不均。少数出口承载了大部分请求，其余出口闲置，整体看起来就是上不去。先看分布，再看总量，这是代理IP并发排查里最省时间的一条经验。
把三个上限分别测一遍，把分布看一遍，再把条件记下来。三件事做完，代理IP的并发这件事基本就清楚了，扩容也不再需要凭感觉。