Lo que hace de la diferencia significativa entre el rendimiento de los eventlet y gevent?

Question

Los dos bibliotecas comparten la misma filosofía y el diseño similar decisiones como resultado.Pero este popular WSGI de referencia dice eventlet es la forma más lenta que gevent.Lo que hacen su rendimiento de manera diferente?

Como puedo saber la clave de las diferencias entre ellos son:

• gevent intencionalmente depende y está acoplado a libev (libevent, anteriormente), mientras que eventlet define independiente de los reactores de la interfaz y la implementa en particular el uso de adaptadores select, epoll, y Trenzado reactor detrás de él. Hace reactor adicional de la interfaz de hacer críticas de rendimiento de los hits?

• gevent es principalmente escrito en Cython, mientras que eventlet está escrito en Python puro. Es compilados de forma nativa Cython tan rápido que Python puro, para los no-tan-mucho-computacional, pero IO-programas dependientes?

• Primitivas de gevent emular bibliotecas estándar de interfaces, mientras que eventlet's primitivas distintos de los estándares y proporciona una capa adicional para que lo parezca. ¿Adicionales capa de emulación hace eventlet más lento?

• Es la aplicación de eventlet.wsgi sólo peor que gevent.pywsgi?

Realmente me pregunto, porque en general se ven tan similares para mí.

Answer 1

Bueno, gevent no es "sobre todo", escrito en Cython, a pesar de que algunas de las secciones críticas son.

Cython hace una gran diferencia.Procesador de optimizaciones trabajo mucho mejor con el código compilado.Rama de predicción, por ejemplo, se cae a pedazos en VM-sistemas basados porque el direccionamiento indirecto de la ramificación en una VM nivel de ejecución es opaco a la misma.La memoria caché es la huella más.Código compilado hace una gran diferencia aquí, y de e / s pueden ser muy sensibles a la latencia.

En una vena similar, libev es muy rápido.Mismas razones.

Parece que no eventlet debe haber estado usando el select hub (Python 2.6 generalmente por defecto epoll).Si estaba atascado en seleccionar, a pesar de que haría realmente lento (debido a que Python tiene que convertir la seleccione fd_set de ida y vuelta a una lista de Python, así que la cosa se pone fea cuando está en medio de un bucle).

No he hecho ninguna de perfiles, pero yo estaría dispuesto a apostar que libev / libevent más Cython hace la gran diferencia.En particular, algunos de los tipos primitivos de subprocesamiento están en Cython en gevent.Este es un gran problema debido a que una gran cantidad de código toca indirectamente a través de IO e incluso la biblioteca estándar en algunos puntos.

Como para el adicional de la capa de emulación de eventlet, parece ser mucho más bounciness.En gevent, la ruta de código parece a construir las devoluciones de llamada y dejar la llamada hub ellos.eventlet parece hacer más de la teneduría de libros que el concentrador está haciendo en gevent.Sin embargo, nuevamente, no he perfilado él.Como para el monkeypatching sí, se ven bastante similares.

El WSGI servidor es otra difícil.En particular, el análisis de encabezado en gevent se aplaza a la biblioteca estándar, mientras que la aplique a sí mismos en eventlet.No estoy seguro si esto es un impacto grande o no, pero no sería una sorpresa si hay algo acechando allí.Más revelador es que eventlet del servidor se basa en un monkeypatched versión de la biblioteca estándar de BaseHTTPServer.No me puedo imaginar que esto es muy óptimo.Gevent implementa un servidor que es consciente de la emulación.

Answer 2

Lo siento por la respuesta tardía.

Hay dos razones principales de la gran diferencia de rendimiento en ese punto de referencia:

• como se dijo antes, gevent de rutas críticas son muy optimizado
• que hace referencia a las pruebas de estrés.No IO obligado más, porque se intenta hacer la máquina para correr como tantas solicitudes como sea posible.Y ahí es donde Cythonized código brilla.

"En el mundo real" que sólo ocurre durante el "slashdot" ráfagas de tráfico.Lo que es importante y debería estar listo, pero cuando ocurre, se debe reaccionar añadiendo más servidores o inhabilitación de los recursos pesada características.No he visto un punto de referencia que añade más servidores cuando aumenta la carga.

Si, por otro lado, el punto de referencia para simular un "día normal" de la carga (que varían de un sitio a otro) pero en general se podría aproximar a solicitud de, al azar de la pausa, repetición.Al menos, esa pausa - más el tráfico que estamos simulando.También el lado del cliente de referencia tendría que simular la latencia.En Linux esto se podría hacer mediante impresionante netem[1], de lo contrario, poniendo pequeños retrasos antes de recibir/enviar llamadas (lo que sería muy difícil porque los puntos de referencia generalmente al uso de mayor nivel de las bibliotecas).

Ahora, si esas condiciones se cumplen, que en realidad lo haría referencia IO obligado problemas.Pero los resultados no demasiado impresionante:todos los candidatos servido con éxito a 10, 50 y hasta 200 qps cargas.Aburrido, ¿verdad?Así, se podría medir la latencia de distribución, tiempo para servir el 99% de las solicitudes, etc.Gevent mostrarían los mejores resultados.Pero la diferencia sería de apenas impresionante.

[1] Simular el retraso y la caída de paquetes en Linux