specify - Python Requests vs PyCurl Performance

install curl python

Question

¿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.

Answer 1

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 4 GB de RAM, en localhost (de Apache en la misma caja), para un archivo de 1 GB, curl y pycurl son 2.5 veces 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.

Answer 2

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 programació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 al usar esa API más amigable.

Answer 3

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 finaliza 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 casos en los 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.

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

• 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 toman aproximadamente 1078 microsegundos de 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.