Interesting about the module loading architecture in nginx. Didn't know it was Nginx being awkward. For all its awesome performance it does have its warts.
For certain pages, where the app server does a lot you're screwed by that as the bottleneck. But if you have very light views, e.g a simple cachable json view it will make sense to make sure you have the best server to get an extra free boost and more responsive and user friendly web page.
some comments:
- it's not uwsgi fault to be in source code; it's an nginx architecture limitation. (hopefully someday it would grow a sane module loading architecture)
- the best number is almost 9.6 better than the worst, but that doesn't mean you can get almost 10x performance in real world. 240 reqs/sec is 4.1ms per request, while 2300 reqs/sec is 0.43ms/req. let's say it's 4ms less per request. But your initial test (with a more like real Django page) was 50reqs/sec or 20ms/req. take 4ms off this time and you get 16ms/req, or 62.5req/sec, just 25% improvement. and that's over a patological case. IOW: better optimize the app (with good DB queries and good caches), and forget about the server.
if it's caheable, put it in memcached and nginx can fetch it directly, without calling the app. in fact, you could even write to a ephemeral file; nginx is just as fast on the filesystem as memcached on RAM
Much of stuff here on peterbe.com is done that way. I benchmarked the hell out of that too and found it much much faster than Varnish and Varnish was much faster than Squid. It's a bit clunky to invalidate but when it works it works wonders.
Some consider the module system of nginx to be a strength.
Dynamic loading would be a decent middle ground, but there are benefits to making modules be determined at compile time and inside nginx. Namely, you get a smaller binary with less extraneous code paths that you can EASILY distribute to N servers (because the modules are in the binary).
Comment
Interesting about the module loading architecture in nginx. Didn't know it was Nginx being awkward. For all its awesome performance it does have its warts.
For certain pages, where the app server does a lot you're screwed by that as the bottleneck. But if you have very light views, e.g a simple cachable json view it will make sense to make sure you have the best server to get an extra free boost and more responsive and user friendly web page.
Parent comment
some comments: - it's not uwsgi fault to be in source code; it's an nginx architecture limitation. (hopefully someday it would grow a sane module loading architecture) - the best number is almost 9.6 better than the worst, but that doesn't mean you can get almost 10x performance in real world. 240 reqs/sec is 4.1ms per request, while 2300 reqs/sec is 0.43ms/req. let's say it's 4ms less per request. But your initial test (with a more like real Django page) was 50reqs/sec or 20ms/req. take 4ms off this time and you get 16ms/req, or 62.5req/sec, just 25% improvement. and that's over a patological case. IOW: better optimize the app (with good DB queries and good caches), and forget about the server.
Replies
if it's caheable, put it in memcached and nginx can fetch it directly, without calling the app. in fact, you could even write to a ephemeral file; nginx is just as fast on the filesystem as memcached on RAM
Much of stuff here on peterbe.com is done that way. I benchmarked the hell out of that too and found it much much faster than Varnish and Varnish was much faster than Squid. It's a bit clunky to invalidate but when it works it works wonders.
As an example, I had this resource (/plog/importance-of-public-urls/display-thumbnail/ecs.png
) in Varnish first.
Just ran some benchmarks on it and got a heft 3,500 requests/second. Put it in front of Nginx and re-ran at 7,000 requests/second. That's pretty cool!
Some consider the module system of nginx to be a strength.
Dynamic loading would be a decent middle ground, but there are benefits to making modules be determined at compile time and inside nginx. Namely, you get a smaller binary with less extraneous code paths that you can EASILY distribute to N servers (because the modules are in the binary).