我应该为每个 HTTP 请求使用一个工作线程吗答案

【问题标题】：Should I use one worker thread per HTTP request我应该为每个 HTTP 请求使用一个工作线程吗
【发布时间】：2018-04-05 23:44:00
【问题描述】：

我想同时发送多个 HTTP 请求。我正在使用 Python 的 multiprocessing.dummy.Pool 来执行此操作。这是创建线程池的代码

p = Pool(len(users))

len(users)) 只是请求的数量。

如您所见，我正在为每个请求创建一个线程。这是一个坏主意吗？我应该改为创建一小部分len(users)) 线程吗？

【问题讨论】：

您是否发现当前方法存在任何问题？
不重复，我看不出选择线程/进程/连接数的任何理由，但你可能会喜欢stackoverflow.com/q/2632520/2823755

标签： python multithreading python-requests

【解决方案1】：

我个人建议根据multiprocessing.cpu_count() 的倍数确定大小；这是concurrent.futures.ThreadPoolExecutor 采用的方法，使用5 * multiprocessing.cpu_count() 理论认为线程工作会阻塞很多，因此您需要比内核更多的线程；如果你有一个巨大的互联网管道，更高的倍数可能是有意义的。如果您愿意，可以将其限制为min(len(users), 5 * multiprocess.cpu_count())（这样可以避免在没有任务使它们饱和时分配过多的线程）。

您不想为每个任务使用一个线程，因为线程和打开的句柄存在限制，这在许多系统上可能以相当低的值出现，并且尝试一次执行所有操作可能会破坏这种情况大约 10,000 多个请求。鉴于您的 Internet 连接可能无法从并行性中受益，超过某个点，您只会浪费更多线程的资源。

【讨论】：

我想我实际上会使用与线程不同的方法。在 python 中有一个叫做 asyncio 的东西。我认为这就像linux中的选择功能？这个想法是你发送非阻塞请求，然后等待其中任何一个完成？
@JRG：有点。 Python 有一个 select（在现代 Python 中是 selectors）模块，它是一个直接接口，但是是的，异步功能可以做类似的事情（尽管如果你经常使用它们，它们往往会劫持整个程序设计）。