Requêtes Python vs PyCurl Performance
Comment la bibliothèque Requests se compare-t-elle avec les performances de PyCurl?
D'après ce que je comprends, Requests est un wrapper python pour urllib, tandis que PyCurl est un wrapper python pour libcurl qui est natif. PyCurl devrait donc offrir de meilleures performances, mais sans savoir de combien.
Je ne trouve pas de points de comparaison.
Je vous ai écrit un point de référence complet }, à l'aide d'une application Flask triviale soutenue par gUnicorn/meinheld + nginx (pour les performances et HTTPS), et voir le temps nécessaire pour exécuter 10 000 demandes. Les tests sont exécutés dans AWS sur une paire d'instances c4.large non chargées, et l'instance de serveur n'était pas limitée par le processeur.
TL; DR résumé: si vous utilisez beaucoup de réseaux, utilisez PyCurl, sinon utilisez des requêtes. PyCurl termine les petites requêtes 2x-3x aussi rapidement que les requêtes jusqu'à atteindre la limite de bande passante requise pour les requêtes volumineuses (environ 520 Mo/s ou 65 Mo/s ici), et utilise de 3 à 10 fois moins la puissance du processeur. Ces chiffres comparent les cas où le comportement de regroupement de connexions est identique. Par défaut, PyCurl utilise le regroupement de connexions et les caches DNS, contrairement aux demandes. Une implémentation naïve sera donc 10 fois plus lente.
Notez que les tracés logarithmiques doubles ne sont utilisés que pour le graphique ci-dessous, en raison des ordres de grandeur impliqués
- pycurl prend environ 73 microprocesseurs pour émettre une demande lors de la réutilisation d'une connexion
- requêtes prend environ 526 CPU-microsecondes pour émettre une requête lors de la réutilisation d'une connexion
- pycurl nécessite environ 165 microprocesseurs pour ouvrir une nouvelle connexion et émettre une demande (aucune réutilisation de la connexion), ou environ 92 microsecondes pour ouvrir
- demande prend environ 1078 CPU-microsecondes pour ouvrir une nouvelle connexion et émettre une demande (aucune réutilisation de connexion), ou ~ 552 microsecondes pour s'ouvrir
Les résultats complets sont dans le lien , ainsi que la méthodologie de référence et la configuration du système.
Mises en garde: bien que je me sois efforcé de garantir la collecte scientifique des résultats, nous ne testons qu'un seul type de système et un seul système d'exploitation, ainsi qu'un sous-ensemble limité de performances, notamment des options HTTPS.
Tout d’abord, requests est construit sur la bibliothèque urllib3 , les bibliothèques stdlib urllib ou urllib2 ne sont pas du tout utilisées.
Il est inutile de comparer requests avec pycurl sur les performances. pycurl peut utiliser le code C pour son travail, mais comme toute programmation en réseau, votre vitesse d'exécution dépend en grande partie du réseau qui sépare votre machine du serveur cible. De plus, le serveur cible pourrait être lent à répondre.
En fin de compte, requests dispose d'une API beaucoup plus conviviale, et vous constaterez que vous serez plus productif avec cette API plus conviviale.
Se focaliser sur la taille -
Sur mon Mac Book Air avec 8 Go de RAM et un SSD de 512 Go, pour un fichier de 100 Mo à 3 kilo-octets par seconde (à partir d'Internet et du wifi), pycurl, curl et la fonction de récupération de la bibliothèque de requêtes ou en streaming) sont à peu près les mêmes.
Sur un plus petit Quad core Intel Linux Box avec 4 Go de RAM, sur localhost (d’Apache sur le même boîtier), curl et pycurl sont 2,5 fois plus rapides que la bibliothèque 'request'. Et pour les demandes, le chunking et le streaming ensemble donnent un coup de pouce de 10% (tailles de chunk supérieures à 50 000).
Je pensais que j'allais devoir échanger des demandes contre pycurl, mais pas tant que l'application que je crée ne va pas avoir le client et le serveur aussi fermés.