This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.最新结论（置顶更新）
2023年6月16日：在安装了最新python-pycurl环境后，发现pycurl在多线程/多进程方面和requests的规律一致了。
注：这里的pycurl指的是性能最高的，基于openssl的pycurl . apt-get提供的那个垃圾pycurl就不测了。
现在假设有2种preload.py代码，它们的区别只有“使用pycurl执行httpGET还是使用requests执行httpGET“，现在评价他们的优劣：
先试试pycurl
在一个2核的vps上，使用基于pycurl的preload.py，如果设置ThreadPoolExecutor为2，那么：
我们会发现pycurl很难占满100% cpu
即使把ThreadPoolExecutor设置为4也不行：
P.S. 虽然ThreadPoolExecutor=4时的pycurl占用cpu看起来不太稳定，但程序执行的总时间是非常稳定的。
把ThreadPoolExecutor设置为8试试：
终于差不多占满了，消耗27秒
下面试试requests版本的preload.py，ThreadPoolExecutor=2 ：
消耗时间也是27秒，而且占用cpu和pycurl-ThreadPoolExecutor=8基本上一样（都是持续93%~94%）
所以结论：
pycurl和requests性能几乎完全一致，至少在我的preload.py上不存在所谓“pycurl更快”的结论（赶紧把之前发过的文章改一改吧）
使用pycurl，不容易精确控制多线程消耗cpu的比例，要反复调ThreadPoolExecutor
使用requests，目前来看的话通过调整ThreadPoolExecutor就能轻松控制cpu占用率，ThreadPoolExecutor=cpu核数=基本占满
但我现在的vps只有2核，要想调出那种“cpu使用率大概80%”的preload.py（想要给其他程序，尤其是nginx-fastcgi留点cpu），就要使用pycurl. 如果使用requests，就要面临：“ThreadPoolExecutor=2=太慢，ThreadPoolExecutor=4=太紧张”的问题。
更新补充：
2023-06-16，重新安装了一遍python3环境后，突然发现不太对：
ThreadPoolExecutor=4占了100%的cpu，用时28秒
ThreadPoolExecutor=2如下图所示：（也用时28秒）
换成ProcessPoolExecutor=2也是一样的效果：
当然，ProcessPoolExecutor=1就是标准的单线程（毫不意外）：
