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