-----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----- _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
