多开时算地址够不够用，很多人只算一个数：实例几个就买几个。跑起来才发现，同样数量的代理IP，有的能撑十个实例，有的三个就开始卡。差别在别的地方：连接时长、请求频次、地址的共用程度，这几项一起决定了实际能撑多少，只数实例数一定算不准。
数量是分子，时长和频次是分母。
先看连接能挂多久
挂得越久，同样的地址越吃紧。
- 连接时长
- 长连接一直占着，地址周转不过来
- 请求频次
- 频次高握手多，握手最耗资源
- 共用程度
- 同段共用的人越多，高峰期越挤
按这三个变量重新算一遍，得出来的数字往往跟按实例数算差很远。长连接占着不释放，五个实例就可能占满十个代理IP的容量；短请求周转快，十个实例三个地址也能撑下来。算清楚再买，比买多了闲置划算，也比买到一半不够用强。
真正决定上限的是握手次数，不是传输量。传输走的是带宽，握手走的是连接数，后者往往先到顶。高频短请求的场景，把请求间隔拉开一点，效果比加地址明显，成本还低。
怎么估自己的实际用量
跑一天，记录三个数：同时在线的实例峰值、每小时握手次数、被拒的比例。三个数凑齐，容量就有底了。被拒比例超过百分之五，说明已经贴着上限在跑，再加两个实例就会集体变慢。
估的时候别忘了峰值和均值差多少。多数业务白天平稳、晚上集中，按均值配的容量在晚上一定不够，白天又闲着浪费。容量按晚高峰配，闲时可以闲置，这是必要的浪费，比晚高峰集体卡住强得多。
什么时候加地址，什么时候优化代码
被拒比例高、握手次数也多，是容量不够，加地址。握手次数正常、被拒比例还高，多半是请求模式有问题，重试太密或者超时设得太短，优化配置比加代理IP见效快。
还有一种情况是地址够用但表现不好，那是资源质量的问题，跟容量无关。这两件事要分开判断，判断错了，钱花了问题还在。
先把手里的三个数清楚，再决定买多少，比先买再省划算。