“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.”
William A. Wulf
Since my last article about performance comparison of popular CMSs: Typo3, Joomla!, and Drupal [typo3-joomla-and-drupal-cmss-performance-testing.html] I got enormous amount of messages, emails and notes.
Most discussed question is:
*What the hell you didn’t turn cache on, and forgot about optimization?
And comments like:
In case of optimization zzz will take first place.
No one runs systems like that in real life. Every real web server is optimized for performance ..
I answered several times with:
I make tests to test effectiveness of pure systems rather then caching sub-system or optimization methods.
Developers should think about effectiveness of their components and don’t pass care about performance entirely to caching or other technics.
Surely cache is good as well as better CPU, bandwidth, and cluster when solution is already got all benefits of good software design.
But if you want OK.
I will turn ON everything I know on all CMSs, and will make all environment optimizations. I hope you will be glad.
Surely if you are hacker that want to tune all the daylights you will beat any system.
Let’s think that this environment presents common set of optimizations on general production system.
OS: Debian GNU/Linux lenny/sid (testing)
kernel: 2.6.22, optimized for current computer configuration
web-server API: apache2.0 handler
processing model: mpm-prefork [http://httpd.apache.org/docs/2.0/mod/prefork.html]
MaxClient adapted for load
excessive login disabled
XCache PHP opcode cacher installed [http://xcache.lighttpd.net/]
xcache.cacher = On
xcache.optimizer = On
xcache.coverager = Off
xcache.size=64M # cache size
xcache.count=2 # cpu count
xcache.var_size = 64M # variable data cache size
xcache.var_count = 2 # cpu count
mysqli database adapter used where appropriate
bin log disabled
query_cache_limit = 2M # default was 1M
query_cache_size = 64M # default was 16M
table_cache = 256 # default was 64
key_buffer_size = 64M # default was 16M
CMSs returned specially prepared page contains:
menu, login form, 2 articles with overall size 40Kb
Testing series contains results for 10, and 20 simultaneous users.
results in the tables are presented in milliseconds per page request
and surely smaller result is better.
|90% results line||145||30||103|
|90% results line||357||72||318|
Drupal uses caching mechanism more effectively that explains such lag of others.
Numbers, and graphs are very loud, and so I think you don’t need any additional descriptions.
You can always compare this result with result without optimization techniques using my previous article [typo3-joomla-and-drupal-cmss-performance-testing.html].