This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
2024年11月的结论
2024年11月：由于现在已经不使用多核preload.py了，在单线程方面我还是认为pycurl性能要强一点。
和过去的结论暂时没什么可比性，因为过去主要纠结于“整个vps火力全开哪个更快“，现在纠结于”使用一个核心（或者说使用一半的核心）哪个更快“。
过去一年我都使用这样的配置：
pycurl+单核( ThreadPoolExecutor(max_workers=1) )
性能也很稳定，最近一个月preload.py的运行时间基本上是68秒上下浮动。
然后我把preload.py里的pycurl代码换成了requests
马上就变成了77秒
切回pycurl
马上变回了66秒
不信邪，又试了一次，还是一样的结果
| requests | 77.68358087539673 |
| pycurl | 67.38518953323364 |
| requests | 77.76420617103577 |
| pycurl | 68.37540197372437 |
当然到这里还不能武断下结论，因为cpu使用率可能不一样！如果requests消耗的系统资源比pycurl低，那么总运行时间多出10秒也是非常合理的。（但事实并不是这样）
然后我去翻了上面4次preload对应的cpu使用率（系统当时基本没有其他消耗cpu的进程在运行）：
基本可以认为消耗的系统资源一致。也就是说，在使用了相同的系统资源的情况下，requests要比pycurl更费时。
2023年6月的结论
2023年6月16日：我认为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就是标准的单线程（毫不意外）：
