设置不同的线程数，为什么扫描速度没有变化？

[taomujian]

我针对某个目标使用默认的字典进行目录扫描时，分别设置线程50和100时，总耗时都是5分钟，为什么没有耗时没有明显变化呢？

[zangcc]

我猜整个链路的瓶颈不在你的发送端（客户端），而在于接收端（服务端）。可能是目标服务器（或其前置的 WAF、CDN、Nginx/Apache）配置了基于 IP 的速率限制。无论你开多少线程，有效吞吐量被服务端“锁死”了

[taomujian]

我猜整个链路的瓶颈不在你的发送端（客户端），而在于接收端（服务端）。可能是目标服务器（或其前置的 WAF、CDN、Nginx/Apache）配置了基于 IP 的速率限制。无论你开多少线程，有效吞吐量被服务端“锁死”了

感觉并不是这个问题，我自己启的一个Web服务(没有WAF、CDN、Nginx/Apache)用来测试，也是这样的问题，分别设置线程50和100时，总耗时没有明显的变化。

[zrquan]

因为 GIL 的存在，多线程里真正做到并行的只有“等待响应”，所以如果你在本地测试，请求几乎没有延迟的情况下，提高线程数并不会提升性能，甚至可能因为上下文切换导致耗时更长

[maurosoria]

你们有试过用 --async 模式吗？在本地低延迟环境下，多线程很容易被 GIL 和调度开销限制，而异步 I/O 往往能把吞吐量拉开。

[zrquan]

@maurosoria Asynchronous mode just avoids the overhead of thread context switching, but it still can't use multi-core CPUs. So, I'm not sure that asynchronous mode will make much of a difference in low-latency situations.

[maurosoria]

Context switching is the worse. In the following python versions they will completely allow us to disable GIL (which doesn't allow real multi thread) so probably in the following versions we will use disabled GIL with a thread for each CPU core. That mixed with asynchronous mode would allow a faster experience. For now, async mode is recommended to avoid CPU starvation and context switching.