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

[Manlio Perillo]

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

Il 13/12/2011 06:45, Roberto De Ioris ha scritto:
> 
>>
>>
>> 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.
> 

Grazie per la conferma!

> [...]
>
> 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).
> 

Il "trucco" è usare un socket UNIX domain bidirezionale, invece di due pipe.
In questo modo per Nginx la comunicazione con il processo CGI dovrebbe
essere analoga a quella con un client remoto.
In particolare non dovrebbe mai essere necessario chiamare waitpid.


Ciao  Manlio

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

iEYEARECAAYFAk7nu+8ACgkQscQJ24LbaURSQQCfXfDvuTer/IBRro1wsFE82qsO
FKUAniwhjPicHKRYss4TCdR8RbuWRPpU
=6awY
-----END PGP SIGNATURE-----