[Python] cgi ottimizzati ERA: web: sync vs. async

[Roberto De Ioris]

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

Ho trovato un po' di tempo per tentare questo approccio:

http://projects.unbit.it/uwsgi/wiki/CGI#Example10:optimizingCGIs

effettivamente il guadagno prestazionale c'e', e anche tanto.

Un "Hello World" su cgi classico su una macchina monoprocessore abbastanza
scarsa (tra l'altro virtualizzata con virtualbox) fa circa 15 richieste al
secondo. Usando la libreria c che c'e' nel link (scritta in 5 minuti, ma
che puo' essere sicuramente migliorata) ne fa 35 (!!!). E' piu' del
doppio, senza dover riscrivere una sola linea dei propri cgi. Io ad
esempio preferisco quasi sempre eseguire mercurial come cgi, questo
approccio mi sarebbe molto utile.

Il "problema", e' che infilare i CGI in nginx (intendo senza passare per
uWSGI) e' fuori discussione (almeno per linux) poiche' tutte le wait()
sono bloccanti e anche usando WNOHANG sarebbe richiesto uno sforzo non
indifferente al core di nginx (che dovrebbe chiamare waitpid() a
intervalli regolari per vedere se qualcosa e' cambiato). Nei BSD sarebbe
molto piu' facile, perche' kqueue() puo' rimanere in attesa di un processo
oltre che di un file descriptor (bellissimo).

-- 
Roberto De Ioris
http://unbit.it