Python Requests vs PyCurl Performance

¿Cómo se compara la biblioteca de solicitudes con el rendimiento de PyCurl?

Entiendo que Requests es un envoltorio de python para urllib, mientras que PyCurl es un envoltorio de python para libcurl que es nativo, por lo que PyCurl debería obtener un mejor rendimiento, pero no está seguro de cuánto.

No puedo encontrar ninguna comparación comparativa.

Le escribí un punto de referencia completo , utilizando una aplicación trivial de Flask respaldada por gUnicorn / meinheld + nginx (para rendimiento y HTTPS), y viendo cuánto tiempo lleva completar 10.000 solicitudes. Las pruebas se ejecutan en AWS en un par de instancias c4.large descargadas, y la instancia del servidor no estaba limitada por la CPU.

TL; resumen de DR: si está haciendo una gran cantidad de redes, use PyCurl, de lo contrario use las solicitudes. PyCurl termina las solicitudes pequeñas 2x-3x tan rápido como las solicitudes hasta que alcanza el límite de ancho de banda con solicitudes grandes (alrededor de 520 MBit o 65 MB / s aquí), y utiliza de 3x a 10x menos de potencia de CPU. Estas cifras comparan los casos en que el comportamiento de agrupación de conexiones es el mismo; de forma predeterminada, PyCurl usa la agrupación de conexiones y los cachés de DNS, donde las solicitudes no, por lo que una implementación ingenua será 10 veces más lenta.

Tabla combinada-RPS Tiempo de CPU por tamaño de solicitud detallado

Sólo el rendimiento HTTP Sólo HTTP RPS

Tenga en cuenta que los gráficos de registro doble se utilizan solo para el siguiente gráfico, debido a los órdenes de magnitud involucrados Rendimiento HTTP y HTTPS HTTP y HTTPS RPS

  • Pycurl tarda aproximadamente 73 microsegundos de CPU para emitir una solicitud al reutilizar una conexión
  • las solicitudes toman aproximadamente 526 microsegundos de CPU para emitir una solicitud al reutilizar una conexión
  • pycurl tarda aproximadamente 165 microsegundos de CPU para abrir una nueva conexión y emitir una solicitud (sin reutilización de la conexión), o ~ 92 microsegundos para abrir
  • las solicitudes requieren aproximadamente 1078 microsegundos de la CPU para abrir una nueva conexión y emitir una solicitud (sin reutilización de la conexión), o ~ 552 microsegundos para abrir

Los resultados completos se encuentran en el enlace , junto con la metodología de referencia y la configuración del sistema.

Advertencias: aunque me he esforzado por garantizar que los resultados se recopilen de una manera científica, solo está probando un tipo de sistema y un sistema operativo, y un subconjunto limitado de rendimiento y especialmente las opciones de HTTPS.

En primer lugar, las requests se crean sobre la biblioteca urllib3 , las bibliotecas stdlib urllib o urllib2 no se utilizan en absoluto.

No tiene mucho sentido comparar las requests con pycurl sobre el rendimiento. pycurl puede usar el código C para su trabajo, pero como toda la progtwigción de red, su velocidad de ejecución depende en gran medida de la red que separa su máquina del servidor de destino. Además, el servidor de destino podría tardar en responder.

Al final, las requests tienen una API mucho más amigable con la que trabajar, y encontrarás que serás más productivo usando esa API más amigable.

Centrándose en el tamaño

  1. En mi Mac Book Air con 8GB de RAM y un SSD de 512GB, para un archivo de 100MB que llega a 3 kilobytes por segundo (desde Internet y wifi), pycurl, curl y la función de obtención de la biblioteca de solicitudes (independientemente de la fragmentación o transmisión) son prácticamente lo mismo.

  2. En una caja Intel Linux de cuatro núcleos más pequeña con 4GB de RAM, en localhost (de Apache en la misma caja), para un archivo de 1GB, curl y pycurl son 2.5x más rápidos que la biblioteca de “solicitudes”. Y para las solicitudes, el agrupamiento y la transmisión en conjunto proporcionan un aumento del 10% (tamaños de fragmentos superiores a 50,000).

Pensé que iba a tener que intercambiar solicitudes por Pycurl, pero no así porque la aplicación que estoy haciendo no va a tener el cliente y el servidor tan cerca.