CPU线程数是否会限制Locust的USERS参数对应的峰值并发用户数？

1. 两者运行逻辑是否一致？ #

完全不一致

• 你熟悉的Java默认使用1:1内核线程模型，每一个Java线程对应一个操作系统级别的CPU线程，调度由操作系统内核完成，所以并发执行的上限直接和物理CPU线程数挂钩。
• Locust默认基于Python的gevent协程库实现，USERS参数对应的是协程级别的虚拟用户，单个操作系统线程就能承载数十到上百个协程，协程的调度在用户态完成，上下文切换开销远低于操作系统线程。

2. USERS设为25、VM仅支持12个CPU线程时的运行情况 #

绝大多数场景下不会出现最多只能并行12个操作、剩余任务等待的情况

• 常规的接口性能测试场景中，压测任务90%以上的时间都在等待IO（比如等待被测服务的响应、网络传输、数据库操作返回等），协程在进入IO等待状态时会主动让出CPU资源给其他协程运行，所以25个协程用户完全可以同时处于活跃状态，不会因为CPU线程只有12个就出现大面积阻塞。
• 只有当你的Locust压测逻辑属于CPU密集型（比如内置了大量加解密、复杂数据计算逻辑，几乎没有IO等待），才会出现CPU线程被占满，后续任务需要排队执行的情况，此时并行上限才会对齐12个CPU线程的限制。

实际使用提示：普通接口压测场景下，12线程的VM跑数百个Locust用户都不会成为瓶颈，只有当你观测到Locust进程CPU占用打满、同时压测QPS无法继续上升的时候，才需要考虑调整用户数或者扩容压测节点。

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