Last time I tested nginx + FastRouter was still noticeably faster than plain uwsgi with HttpRouter
http://lists.unbit.it/pipermail/uwsgi/2014-April/007203.html 2014-08-05 15:48 GMT+02:00 Roberto De Ioris <[email protected]>: > > > Hi, > > > > With the current feature set of uWSGI, what could be the reasons to use > > Nginx + uWSGI combo over standalone uWSGI? > > > > Why I am asking this: the most of tutorials I find assume you want to set > > up uWSGI + Nginx stack (without explaining why). The current incarnation > > of > > uWSGI can do both SSL and static file serving fine. It even gives out > > compatible access.log (with some tinkering). I assume these tutorials > were > > written by the time when uWSGI did not have as many features as it does > > today. > > > > If you want to keep your stack simple (as we all do) would one recommend > > setting up standalone uWSGI unless there is some specific reason to go > for > > Nginx? > > > > Here is my pet project (SSL, static files) etc. running on plain uWSGI > > directly in port 80 and 443. I have not encountered any problems yet, but > > I'll let you know if I hit something: > > > > https://github.com/miohtama/LibertyMusicStore > > > > Cheers from Finland, > > Mikko > > > > > > Short answer: > > nginx is faster in http parsing and load balancing, has more web-server > related features and has no gray areas. > > Long answer: > > uWSGI gray areas are the main problem. > > uWSGI is a generic library for building web applications and hosting > services, > lot of common choices in webservers (like nginx) are instead demanded to > the user, so to have a fully compliant http webserver on top of uWSGI you > will need dozens of configuration lines and (more important) you need to > choose how to behave on various conditions. > > As an example uWSGI routers brutally closes connections on error, instead > of sending 502/503 response. Management of Range headers must be enabled, > as well as request buffers. Only Last-Modified is managed (Etag and other > cache header must be manually managed) > > You can probably configure uWSGI to behave 1:1 as nginx, but very probably > you will end with a slower implementation. > > > Having said that, lot of users are now satisfied with the uWSGI > http/https/spy router as they need it only for "routing" (read the domain > -> forward to backend). In such simple scenario (maybe combined with > something like cloudfront) it could be a good choice as uWSGI allows > dynamic configuration of backends. (and this is the only thing, from the > web-server point of view, in which uWSGI is better than nginx) > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
