>> >> it is a bit harder to setup > > are you joking ? > search this group and u will see my comments using uwsgi on webfaction > > nginx <-socket-> uwsgi+python > > u can use builtin webserver and u will not have layers at all > and SCGIServer is written in python which makes it slower > > it scales smoothly on multicores > > uwsgi has master and slave processes, > also has uGreen module (~ greenlet) - > u see: master->child processes->ugreenlets (if I can say so) - that makes > it > able to handle much more requests than scgiserver can > > and not very least feature: it is STABLE > also it is able to reload child processes, > can limit the memory for child processes and many many features, > and still FASTER > > and a very, very nice feature is touch reload when testing routes > > I respect ur contribution, but u didn't convinced me that scgi is better > than uwsgi >
Come on, no need to fight :) I do not think Michele is saying that SCGI (that remember is only a communication protocol) is better than something else. Even Cherokee (albeit being a uWSGI supporter) uses SCGI pure-python for its admin interface. Implementing SCGI in python is very easy (no more than a dozen of lines) so if you only need a gateway (and not a deployment platform) it could be a very good choice. The Michele analysys about performance is a bit wrong as he should say: (for scgi) webserver <-> socket <-> python scgi parser <-> web2py (for uWSGI with uwsgi protocol) webserver <-> socket <-> C uwsgi parser <-> web2py But generally, if you need to attach an app to a webserver, implementing SCGI is the easiest choice (both uwsgi and fastcgi are binary protocol, and writing good http parser is not the easiest task in the world) -- Roberto De Ioris http://unbit.it
