[Python] web: sync vs. async

[Manlio Perillo]

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

Il 04/12/2011 10:59, Roberto De Ioris ha scritto:
> [...]
> Per quanto riguarda uWSGI ha il supporto "asincrono" da un paio d'anni
> (tra l'altro lo scrissi proprio per usare psycopg2/psycogreen)
> 
> http://projects.unbit.it/uwsgi/wiki/AsyncSupport
> 
> a cui poi si e' aggiunto subito dopo un motore co-routine indipendente dal
> linguaggio:
> 
> http://projects.unbit.it/uwsgi/wiki/uGreen
> 
> rispetto a greenlet era (ed e') piu' veloce ma occupa un fottio di memoria
> in piu' (prealloca tutti gli stack)
> 

Si, questo è il problema maggiore con le coroutine.
In parte il problema si può ridurre allocando memoria virtuale, ma il
problema di fondo resta.

Tempo fa lessi il codice del runtime di GHC (compilatore per Haskell)
che implementa un modello a microthread, ma non ci ho capito niente ;-).

So solo che ciascun micro thread richiede poca memoria, però il runtime
deve controllare eventuali stack overflow e riallocare lo stack.

> Da un annetto uGreen puo' essere sostituito sia da greenlet che da
> stackless python in modo trasparente (rimane quindi la stessa funzione
> uwsgi.suspend()).
> 

Io devo ancora capire greenlet come gestisce il problema dello stack.
So che copia delle aree di memoria, ma non so bene cosa.

> [...]
> Se leggi il disclaimer del primo link, capirai bene come la penso su
> questo stile di programmazione, e presumo che Manlio la pensi ugualmente
> ecco perche' consiglia un approccio piu' semplice (e io oserei dire anche
> "robusto"). 


Si, su questo la pensiamo allo stesso modo.

> Se non si ha bisogno di scalare a livelli inumani, non serve a
> niente andare a cambiare tutta la logica di sviluppo. I thread di python
> saranno "castrati" dal GIL ma il loro scopo e' aggiungere concorrenza, le
> performance diventano secondarie.
> Se si vuole sfruttare l'SMP basta andare di preforking+threads (o solo
> preforking che va bene nel 99.999% dei casi).

Io stavo valutando un altra strada (nel caso in cui non serva un elevato
grado di concorrenza): il buon vecchio CGI.
Ovviamente non CGI normale, ma fare in modo che l'interprete Python sia
embedato nel server (e pre-caricare in memoria quanto più possibile
specialmente se read-only) e poi fare un fork + Python exec.

Rispetto ad un CGI normale (fork + sys exec) mi aspetto un miglioramento
significativo, anche grazie al copy-on-write.

Lo volevo fare in Nginx e, per riutilizzare tutta l'infrastruttura,
usare 1 UNIX domain socket invece che 2 pipe, ma non è banale e richiede
di patchare il codice di Nginx.

> [...]


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

iEYEARECAAYFAk7blFsACgkQscQJ24LbaUSKVACfdfDx5PLAlMDe8eADtso9TJlM
MMQAnRXJM9t1Sl4bGUrUvNLd+0kJbBPl
=3jIy
-----END PGP SIGNATURE-----