各类经验贴给出的阈值从两个到八个都有，看起来互相矛盾，各自对应的前提却不同。设备规格不同、代理IP线路质量不同、操作方式不同，能承载的数量自然不同。把别人环境下的数字搬过来当标准，多数会出现两种情况：要么过度保守，明明能跑更多却不敢加；要么过度激进，加到超出承载才出问题。两种情况的代价都不小，前者浪费预算，后者影响稳定。
阈值不是常数，它随设备、线路、操作方式一起变。
- 先测设备上限 逐步增加实例，观察 CPU、内存、磁盘占用的变化
- 再测线路承载 固定实例数量，观察延迟、掉线率、连接数的变化
- 最后测操作方式 同样数量下，分别手动处理与统一流程推进，表现是否不同
- 记下三组结果 三组数据合起来，才是自己这套环境的实际容量
三步要分开测，混着测得出的结论没法归因。设备吃紧和线路吃紧的表现不同，前者是整体卡顿，后者是连接不稳。两者同时出现时，先加设备还是先加代理IP线路，判断依据就是这三组数据。分开测多花两天，省下的是之后无数次的反复调整。
为什么这类阈值传得这么广
因为它好记。一个具体数字比一套测法更容易传播，也更容易被当成答案。答案的价值在适用，不适用的答案比没有答案更麻烦，它会让人在一个错误的方向上反复加码，加到最后把原本够用的环境也拖慢。
测出来之后怎么用
当成基线，不当成上限，这条对任何阈值都成立。基线是当前环境下比较稳的状态，环境变化时对照着看，能立刻判断是不是超了。
基线多久更新一次
换了设备、换了代理IP线路、操作方式有调整，这三种情况之后重新测一轮。环境没变就不必重测，把上一次的数据留着对照就够用。
阈值这件事没有一劳永逸的答案，只有一份跟着环境走的实测数据。把它记下来，比背任何数字都管用。