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 pycurl | 1.0% ~ 1.4% |
| pip安装，限定--with-nss | 1.4% ~ 1.8% |
| pip安装，限定--with-openssl 使用Linux发行版自带的老版本libcurl | 4.2% ~ 4.6% |
| pip安装，限定--with-wolfssl | 10% ~ 13% |
| apt install python3-pycurl | 14% ~ 16% |
| 把测试程序里的pycurl改为requests | 14% ~ 16% |
Last Modified in 2023-04-12
