Greenlet vs. discussioni

Sono nuovo di gevents e greenlets. Ho trovato una buona documentazione su come lavorare con loro, ma nessuno mi ha dato giustificazioni su come e quando dovrei usare i greenlet!

• In cosa sono veramente bravi?
• È una buona idea usarli in un server proxy o no?
• Perché non le discussioni?

Ciò di cui non sono sicuro è come possono fornirci la concorrenza se sono fondamentalmente co-routine.

I greenlet forniscono concorrenza ma non parallelismo. La concorrenza è quando il codice può essere eseguito indipendentemente da altro codice. Il parallelismo è l'esecuzione simultanea di codice simultaneo. Il parallelismo è particolarmente utile quando c'è molto lavoro da fare nello spazio utente, e in genere è roba pesante per la CPU. La concorrenza è utile per risolvere i problemi, consentendo di programmare e gestire più facilmente diverse parti in parallelo.

I greenlet brillano davvero nella programmazione di rete in cui le interazioni con un socket possono avvenire indipendentemente dalle interazioni con altri socket. Questo è un classico esempio di concorrenza. Poiché ogni greenlet viene eseguito nel proprio contesto, è possibile continuare a utilizzare le API sincrone senza thread. Questo è positivo perché i thread sono molto costosi in termini di memoria virtuale e sovraccarico del kernel, quindi la concorrenza che puoi ottenere con i thread è significativamente inferiore. Inoltre, il threading in Python è più costoso e più limitato del solito a causa del GIL. Le alternative alla concorrenza sono in genere progetti come Twisted, libevent, libuv, node.js ecc., In cui tutto il codice condivide lo stesso contesto di esecuzione e registra i gestori di eventi.

È un'ottima idea utilizzare i greenlet (con il supporto di rete appropriato come tramite gevent) per scrivere un proxy, poiché la gestione delle richieste è in grado di essere eseguita in modo indipendente e deve essere scritta come tale.

I greenlet forniscono concorrenza per i motivi che ho indicato in precedenza. La concorrenza non è parallelismo. Nascondendo la registrazione degli eventi ed eseguendo la pianificazione per le chiamate che normalmente bloccherebbero il thread corrente, progetti come gevent espongono questa concorrenza senza richiedere la modifica di un'API asincrona ea costi notevolmente inferiori per il sistema.

• La concorrenza non è parallelismo
• Discussioni vs. processi
• Multiprocessing vs. thread
• GIL vs. CPython

Prendendo la risposta di @ Max e aggiungendo una certa rilevanza ad essa per il ridimensionamento, puoi vedere la differenza. Ho raggiunto questo obiettivo modificando gli URL da compilare come segue:

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)

Ho dovuto abbandonare la versione multiprocesso in quanto è caduta prima di avere 500; ma a 10.000 iterazioni:

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

Quindi puoi vedere che c'è una differenza significativa nell'I / O usando gevent

Correggendo la risposta di @TemporalBeing sopra, i greenlet non sono "più veloci" dei thread ed è una tecnica di programmazione errata generare spawn di 60000 thread per risolvere un problema di concorrenza, è invece appropriato un piccolo pool di thread. Ecco un confronto più ragionevole (dal mio post reddit in risposta alle persone che citano questo post 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)

Ecco alcuni risultati:

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

il malinteso che tutti hanno sull'IO non bloccante con Python è la convinzione che l'interprete Python possa occuparsi del lavoro di recupero dei risultati dai socket su larga scala più velocemente di quanto le connessioni di rete stesse possano restituire IO. Anche se questo è certamente vero in alcuni casi, non lo è quasi tutte le volte che la gente pensa, perché l'interprete Python è molto, molto lento. Nel mio post di blog qui , illustrerò alcuni profili grafici che mostrano che per cose anche molto semplici, se hai a che fare con un accesso alla rete rapido e veloce a cose come database o server DNS, quei servizi possono tornare molto più velocemente del codice Python può occuparsi di molte migliaia di tali connessioni.

Questo è abbastanza interessante da analizzare. Ecco un codice per confrontare le prestazioni dei greenlet rispetto al pool di multiprocessing rispetto al 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()

ecco i risultati:

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

Penso che il greenlet sostenga che non è vincolato da GIL a differenza della libreria multithreading. Inoltre, il documento Greenlet afferma che è destinato alle operazioni di rete. Per un'operazione di rete intensiva, il cambio di thread va bene e puoi vedere che l'approccio multithreading è piuttosto veloce. Inoltre è sempre preferibile utilizzare le librerie ufficiali di Python; Ho provato a installare greenlet su Windows e ho riscontrato un problema di dipendenza DLL quindi ho eseguito questo test su un Linux VM. Cerca sempre di scrivere un codice con la speranza che funzioni su qualsiasi macchina.