*** Disclaimer: these are all tests that i do for check on performance regressions, but i think that can be interesting for the list. Beginning a war on the usefulness of raw benchmarks is totally useless and ridiculous. ***
I have done some benchmark on various combinations. I have used 'ab' on Ubuntu Karmic with a Intel(R) Core(TM)2 Duo CPU E8235 @ 2.80GHz apache 2.2.12 and current (trunk) versions of cherokee, flup and uwsgi I have configured a base trac instance and directed all the requests to the homepage. The results are very interesting (i have taken the worst and best results for every combination for 100 requests and 4 concurrency level with 'ab'). apache2 (mpm worker)+mod_uwsgi+uwsgi+trac requests per second -> from 34.70 to 36.40 cherokee+uwsgi_handler+uwsgi+trac requests per second-> from 34.90 to 35.70 cherokee+scgi_handler+flup+trac requests per second -> 30.26 to 32.40 (all the test are executed on unix sockets) The uwsgi server (the python2.6 one) is launched in this way: ./uwsgi26 -p 2 -s /tmp/uwsgi.sock -C -x uwsgi.xml -i flup is launched with 6 forked workers (the default) I think that the bottleneck on the scgi approach is the full-python code in flup that lose a bit of raw-power. I have to say that the apache's mod_uwsgi code is really (really) simple, it has not load balancing nor the x-sendfile support and timeouts are poorly managed. Apache does not even parse the output headers as i use the "assbackwards" directive to gain the best performance. The memory consumed by flup and uwsgi are pratically the same (about 19 megs). Now, adding tcp support (i think a couple of day before it) on the uwsgi server will permit to have ultra-scalable, fast and easy to configure cluster based on cherokee. And obviously there are still a lot of space for optimizations. -- Roberto De Ioris http://unbit.it JID: [email protected] _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
