[Python] web: sync vs. async

Manlio Perillo manlio.perillo a gmail.com
Sab 3 Dic 2011 16:23:28 CET


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 03/12/2011 14:07, Giampaolo Rodolà ha scritto:
> Il 02 dicembre 2011 16:18, Daniele Varrazzo <piro a develer.com> ha scritto:
>> Io ho messo 4 server in ascolto su 4 porte diverse: il primo sulla standard
>> https 443 e altre 8444, 8445, 8446 (la bella copia sarebbe avere 4
>> sub-domain, ma per ora abbiamo solo un certificato ssh).
>>
>> Quando un utente si connette, viene rediretto ad un certo nodo (id utente %
>> n. nodi, per esempio). Da lì in poi tutti i link del programma sono
>> relativi, per cui una volta che è andato sul server https://host:8445, ci
>> resta. Il suo nodo di appartenenza è anche memorizzato al momento del login
>> nella sua sessione del server: ad ogni richiesta viene controllato che sia
>> sul server giusto e, se non lo è, gli viene servito un redirect per
>> mandarcelo.
>>
>> Questa soluzione consente di usare tutte le cpu sulla macchina nella maniera
>> migliore possibile: con diversi processi. Perché funzioni si assume che gli
>> utenti non si scambino dati tra loro se non attraverso il database. Invece
>> poiché un utente resta sempre sullo stesso server, i suoi dati di sessione
>> sono sempre disponibili. Per scalare di più possiamo aggiungere nuovi
>> processi (la nostra macchina ha 16 cpu) o anche aggiungere nuove macchine.
> 
> Una cosa di questo tipo non avrebbe ugualmente funzionato?
> 
> # pseudo codice
> import multiprocessing
> from somehttpd import HTTPServer
> 
> CPUS = multiprocessing.cpu_count()
> server = HTTPServer()
> # create child processes to act as workers
> for x in range(CPUS - 1):
>     Process(target=server.serve_forever).start()
> # main process also acts as a worker
> server.serve_forever()
> 
> 
> Se si, ti saresti evitato l'onere di ascoltare su porte multiple e
> ovviamente tutta la complessità aggiuntiva che ne deriva.
> 

Questo è essenzialmente l'approccio usato da Nginx.

Però c'è un dettaglio subdolo: con questo metodo ciascun processo figlio
chiama la accept sullo stesso file descriptor ereditato dal padre e ci
potrebbero essere dei problemi subdoli.

Ad esempio il problema chiamato "thundering herd" oppure (ma su questo
non riesco a trovare dei riferimenti, l'ho letto dall'autore di Nginx)
il sistema operativo potrebbe **non** distribuire il carico equamente su
tutti i sotto processi.


Ciao  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7aPvAACgkQscQJ24LbaUQ3uQCfd+GtJoeTHfxAyaqF8TotXV3i
lFQAn05dxH/HGX0jIUf8IAlHf680h7ck
=xCId
-----END PGP SIGNATURE-----


Maggiori informazioni sulla lista Python