> Compiled uwsgi 0.9.9.3 (the 0.9.8.1 did not now about pythonpath) > uwsgi --pythonpath /opt/web-apps/web2py --module wsgihandler --http :80 -s > /tmp/we2py.sock >uwsgi.log 2>&1 > > 1 CPU: 17.83 [#/sec] (better than rocket) > 2 CPUs: 17.98 [#/sec] > > uwsgi --pythonpath /opt/web-apps/web2py --module wsgihandler --http :80 -s > /tmp/we2py.sock -M -p2 >uwsgi.log 2>&1 > > 2 CPUs: 31.30 [#/sec] > > I guess with the -p 2 enabled it was not as fast as nginx for static > content.
because you are comparing a preforking (apache-style) approach with a non-blocking one (nginx). For determistic areas (like serving static files) there is no competition. This is why having a non blocking-server on front of the application server is a common setup. Having a front-end will obviously slow-down things, but the impact (as you have already noted) is non-existant. (by the way, --http is still a proxied-setup as the uwsgi http server will run in another process, if you want native http you have to use --http-socket) In addition to this, you have to think about security: nginx, apache, cherokee... are all developed for being front-line servers, and this requires a higher level of security in mind. > > Anyhow, is this a recommended setup? Doesn't it show the same behavior as > gunicorn ( "Without this (nginx) buffering Gunicorn will be easily > susceptible to denial-of-service attacks." ) > as i have already said having a front line server (like --http does) is always a good choice, independently by the front-line server. Nginx has obviously more tolerance in high-concurrency in serving static file (have you tried the --static-map and --check-static option in uWSGI 1.0.x ?), but if you are developing the next amazon, you should really start thinking about using a CDN for your static assets instead of your own webserver. regarding gunicorn, it does only one thing and does it well (TM), its philosophy is towards simplicity, writing logic to check the good-behaviour of your app (like uWSGI morbidly does) is at the opposite of that philosophy. I am perfectly agree with this approach (programmers should fix their apps), but i work in a ISP where customers expect their apps being available as most as possibile and tend to blame the ISP for their fault (yes, it is a ugly world :). That's why uWSGI exists and that's why you cannot compare it with gunicorn (different philosophy and different target) -- Roberto De Ioris http://unbit.it
