最新结论(置顶更新)
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就是标准的单线程(毫不意外):