(Translation of my previous post).
Yesterday I have finally sorted out my trouble with compilation of nginx' mod_wsgi and got it working (how much means slash in our life ;-).
Configuration to get Django application running is quite simple -
django.wsgi, which is used for Apache’s mod_wsgi, fits perfectly. I’ll
not describe all configuration, because code is unstable and needs testing and
is’s contra-indicated to run it on production now.
Lets do the fun - testing. :-) Simple page, 15 queries (PostgreSQL on same pc),
2 workers for nginx (I have tried 3 and 4 - they both are slighty slower, for
2-4 ms). Two variants of testing queries (ab -n 1000 -c 20 and ab -n 10000 -c 500) and three variants of servers (mod_wsgi, prefork fastcgi, threaded fastcgi). Hardware (this is not so interesting, because performance is
interesting only in comparison, but why not to show it?)
- Core 2 Duo T7300 and 2 Gb of RAM.
First - ab -n 1000 -c 20 (around of 10-12 runs for every variant):
mod_wsgitakes 14.2-14.3 ms per query, quite stable performanceprefork fastcgitakes 12.5-16.5 ms (mostly near of 12 ms, but raises from time to time), eats more RAM - I have an xmobar1 showing RAM usage andmod_wsgihas a two-three percents (percent is 20 megs) lesser usagethreaded fastcgitakes 24-25 ms per query - it uses only one core of CPU. I have tried to getupstreamworking innginx- it works, but uses only 1 process for some reason :-(
I.e. in most cases for such load FastCGI is slighty faster (and uses somewhat bigger amount of resources). But… lets go further? ;)
Second - ab -n 10000 -c 500 (here I got 3-4 runs for every variant):
mod_wsgitakes 13-14 ms. Pretty stable result. Each worker consumes 21/15 megs of RAM (VSZ/RSS)prefork fastcgitakes 15.5-17 ms per request, but it runs from 40 to 50 serving instances, each consuming 16-20 VSZ (10-13 RSS) megs of RAM! xmobar says that usage raises up to 50% (by leaps, usually around 45-48%) - compare to 33% formod_wsgi! Additional 300 mbytes of RAM.threaded fastcgi- most “interesting” variant. With this level of concurrency it just dies. With-c 100- dies. It lives with-c 50with slighty lower speed than with-c 20, but process eats near of 300 mb of VSZ.
What I can say here? Lets wait for stable mod_wsgi release! :-) Thanks, Manlio, for creating it. :-)