PycURL的性能取决于安装方法和编译依赖

WARNING: This article may be obsolete
This post was published in 2022-05-27. Obviously, expired content is less useful to users if it has already pasted its expiration date.

PycURL自身内部存在参差不齐的性能差异:使用某些方法编译安装得到的PycURL,性能可能会慢10倍以上!

起因:

在我的服务器上有一个预加载wordpress缓存的python程序(可以视为一个多线程cURL请求器),每次运行这段程序都可以在40~50秒内重新构建全站缓存内容(服务器性能越强,构建缓存的速度越快)。但有一个问题困扰了我半年之久:为什么相同的php-mariadb-nginx架构,在centos/redhat linux上的重构缓存速度永远快于debian系

长期以来我一直把原因错误地归为“VPS母鸡使用的KVM内核版本为2.6,过高的Linux kernel版本可能会带来较大的性能损失”,以及“RedHat可能对RHEL搞了什么特别的内核编译优化”。

但近日我意外发现这些性能差距主要是由PycURL带来的:如果不加区分,在Debian 11系统里使用 apt install python3-pycurl 会得到一个性能极其低下的PycURL,因为它使用了 gnutls !而centos 7的yum不提供PycURL,需要自己手动编译安装(大部分时候都会链接 openssl ),因此逃过一劫。

经过更多测试可知,手动编译最新版本的libcurl --with-openssl(而不是使用apt安装)以及PycURL,可以获得最优性能;如果你不想手动编译,可以使用 conda 安装,也是几乎一样的。

安装方法运行同一个python程序的cpu占比
(使用命令:$ pidstat 5 -p $(pidof python3))
python3 setup.py安装,
限定编译最新的licurl with openssl
1.0% ~ 1.4%
conda install -c anaconda pycurl1.0% ~ 1.4%
pip安装,限定--with-nss1.4% ~ 1.8%
pip安装,限定--with-openssl
使用Linux发行版自带的老版本libcurl
4.2% ~ 4.6%
pip安装,限定--with-wolfssl10% ~ 13%
apt install python3-pycurl14% ~ 16%
把测试程序里的pycurl改为requests14% ~ 16%


 Last Modified in 2023-04-12 


Leave a Comment Anonymous comment is allowed / 允许匿名评论