Greenlet vs. Hilos

Soy nuevo en gevents y greenlets. ¡Encontré una buena documentación sobre cómo trabajar con ellos, pero ninguno me dio justificación sobre cómo y cuándo debería usar greenlets!

• ¿En qué son realmente buenos?
• ¿Es una buena idea usarlos en un servidor proxy o no?
• ¿Por qué no hilos?

De lo que no estoy seguro es de cómo nos pueden proporcionar concurrencia si son básicamente co-rutinas.

Los greenlets proporcionan concurrencia pero no paralelismo. La concurrencia es cuando el código puede ejecutarse independientemente de otro código. El paralelismo es la ejecución de código concurrente simultáneamente. El paralelismo es particularmente útil cuando hay mucho trabajo por hacer en el espacio de usuario, y eso es típicamente un trabajo pesado de CPU. La concurrencia es útil para resolver problemas, ya que permite programar y gestionar diferentes partes más fácilmente en paralelo.

Los greenlets realmente brillan en la programación de red donde las interacciones con un socket pueden ocurrir independientemente de las interacciones con otros sockets. Este es un ejemplo clásico de concurrencia. Debido a que cada greenlet se ejecuta en su propio contexto, puede continuar utilizando API síncronas sin subprocesos. Esto es bueno porque los subprocesos son muy caros en términos de memoria virtual y sobrecarga del núcleo, por lo que la concurrencia que puede lograr con los subprocesos es significativamente menor. Además, el enhebrado en Python es más costoso y más limitado de lo habitual debido al GIL. Las alternativas a la concurrencia generalmente son proyectos como Twisted, libevent, libuv, node.js, etc., donde todo su código comparte el mismo contexto de ejecución y registra controladores de eventos.

Es una excelente idea usar greenlets (con soporte de red apropiado, como a través de gevent) para escribir un proxy, ya que su manejo de solicitudes puede ejecutarse de forma independiente y debe escribirse como tal.

Los Greenlets proporcionan concurrencia por las razones que expuse anteriormente. La concurrencia no es paralelismo. Al ocultar el registro de eventos y realizar la programación para usted en llamadas que normalmente bloquearían el hilo actual, proyectos como gevent exponen esta concurrencia sin requerir cambios a una API asincrónica, y a un costo significativamente menor para su sistema.

• La concurrencia no es paralelismo
• Subprocesos vs. procesos
• Multiprocesamiento vs. hilos
• GIL vs CPython

Tomando la respuesta de @ Max y agregando cierta relevancia para el escalado, puede ver la diferencia. Lo logré cambiando las URL para que se llenen de la siguiente manera:

URLS_base = ['www.google.com', 'www.example.com', 'www.python.org', 'www.yahoo.com', 'www.ubc.ca', 'www.wikipedia.org']
URLS = []
for _ in range(10000):
    for url in URLS_base:
        URLS.append(url)

Tuve que abandonar la versión multiproceso ya que cayó antes de tener 500; pero a 10,000 iteraciones:

Using gevent it took: 3.756914
-----------
Using multi-threading it took: 15.797028

Entonces puede ver que hay una diferencia significativa en E / S usando gevent

Al corregir la respuesta de @TemporalBeing anterior, los greenlets no son "más rápidos" que los hilos y es una técnica de programación incorrecta generar 60000 hilos para resolver un problema de concurrencia, en cambio es apropiado un pequeño grupo de hilos. Aquí hay una comparación más razonable (de mi publicación de reddit en respuesta a las personas que citan esta publicación SO).

import gevent
from gevent import socket as gsock
import socket as sock
import threading
from datetime import datetime


def timeit(fn, URLS):
    t1 = datetime.now()
    fn()
    t2 = datetime.now()
    print(
        "%s / %d hostnames, %s seconds" % (
            fn.__name__,
            len(URLS),
            (t2 - t1).total_seconds()
        )
    )


def run_gevent_without_a_timeout():
    ip_numbers = []

    def greenlet(domain_name):
        ip_numbers.append(gsock.gethostbyname(domain_name))

    jobs = [gevent.spawn(greenlet, domain_name) for domain_name in URLS]
    gevent.joinall(jobs)
    assert len(ip_numbers) == len(URLS)


def run_threads_correctly():
    ip_numbers = []

    def process():
        while queue:
            try:
                domain_name = queue.pop()
            except IndexError:
                pass
            else:
                ip_numbers.append(sock.gethostbyname(domain_name))

    threads = [threading.Thread(target=process) for i in range(50)]

    queue = list(URLS)
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    assert len(ip_numbers) == len(URLS)

URLS_base = ['www.google.com', 'www.example.com', 'www.python.org',
             'www.yahoo.com', 'www.ubc.ca', 'www.wikipedia.org']

for NUM in (5, 50, 500, 5000, 10000):
    URLS = []

    for _ in range(NUM):
        for url in URLS_base:
            URLS.append(url)

    print("--------------------")
    timeit(run_gevent_without_a_timeout, URLS)
    timeit(run_threads_correctly, URLS)

Aquí hay algunos resultados:

--------------------
run_gevent_without_a_timeout / 30 hostnames, 0.044888 seconds
run_threads_correctly / 30 hostnames, 0.019389 seconds
--------------------
run_gevent_without_a_timeout / 300 hostnames, 0.186045 seconds
run_threads_correctly / 300 hostnames, 0.153808 seconds
--------------------
run_gevent_without_a_timeout / 3000 hostnames, 1.834089 seconds
run_threads_correctly / 3000 hostnames, 1.569523 seconds
--------------------
run_gevent_without_a_timeout / 30000 hostnames, 19.030259 seconds
run_threads_correctly / 30000 hostnames, 15.163603 seconds
--------------------
run_gevent_without_a_timeout / 60000 hostnames, 35.770358 seconds
run_threads_correctly / 60000 hostnames, 29.864083 seconds

El malentendido que todo el mundo tiene acerca de no bloquear IO con Python es la creencia de que el intérprete de Python puede atender el trabajo de recuperar resultados de sockets a gran escala más rápido de lo que las conexiones de red pueden devolver IO. Si bien esto es cierto en algunos casos, no es cierto con tanta frecuencia como la gente piensa, porque el intérprete de Python es muy, muy lento. En mi blog aquí , ilustramos algunos perfiles gráficos que muestran que incluso para cosas muy simples, si se trata de un acceso nítido y rápido a redes como bases de datos o servidores DNS, esos servicios pueden volver mucho más rápido que el código Python puede atender a miles de esas conexiones.

Esto es lo suficientemente interesante como para analizar. Aquí hay un código para comparar el rendimiento de los greenlets versus el pool de multiprocesamiento versus multi-threading:

import gevent
from gevent import socket as gsock
import socket as sock
from multiprocessing import Pool
from threading import Thread
from datetime import datetime

class IpGetter(Thread):
    def __init__(self, domain):
        Thread.__init__(self)
        self.domain = domain
    def run(self):
        self.ip = sock.gethostbyname(self.domain)

if __name__ == "__main__":
    URLS = ['www.google.com', 'www.example.com', 'www.python.org', 'www.yahoo.com', 'www.ubc.ca', 'www.wikipedia.org']
    t1 = datetime.now()
    jobs = [gevent.spawn(gsock.gethostbyname, url) for url in URLS]
    gevent.joinall(jobs, timeout=2)
    t2 = datetime.now()
    print "Using gevent it took: %s" % (t2-t1).total_seconds()
    print "-----------"
    t1 = datetime.now()
    pool = Pool(len(URLS))
    results = pool.map(sock.gethostbyname, URLS)
    t2 = datetime.now()
    pool.close()
    print "Using multiprocessing it took: %s" % (t2-t1).total_seconds()
    print "-----------"
    t1 = datetime.now()
    threads = []
    for url in URLS:
        t = IpGetter(url)
        t.start()
        threads.append(t)
    for t in threads:
        t.join()
    t2 = datetime.now()
    print "Using multi-threading it took: %s" % (t2-t1).total_seconds()

aquí están los resultados:

Using gevent it took: 0.083758
-----------
Using multiprocessing it took: 0.023633
-----------
Using multi-threading it took: 0.008327

Creo que Greenlet afirma que no está obligado por GIL a diferencia de la biblioteca de subprocesos múltiples. Además, el documento de Greenlet dice que está destinado a operaciones de red. Para una operación intensiva de red, el cambio de subprocesos está bien y puede ver que el enfoque de subprocesamiento múltiple es bastante rápido. Además, siempre es preferible utilizar las bibliotecas oficiales de Python; Intenté instalar greenlet en Windows y encontré un problema de dependencia de dll, así que ejecuté esta prueba en un linux vm. Siempre trate de escribir un código con la esperanza de que se ejecute en cualquier máquina.