The need for speed
Drupal is a very popular LAMP-based content management system which powers thousands of personal and small-to-medium business websites, and quite a few larger sites as well. It is feature rich and easy to install, configure and use. It is interesting, however, to note comments by Drupal developers at 2bits.com regarding Drupal performance problems brought on by a combination of bloated application code and the platform it runs on (Apache + PHP).
One problem many Drupal installations suffer from is module bloat, partly a result of Drupal's popularity, the size of it's contributor base, and the diversity of contributed modules available. The 2bits developers estimate that a "full featured" Drupal site runs between 80 to 100 modules, and have seen sites with up to 122 modules. They ran tests on a site with 113 modules, and showed that this produced an Apache process of around 95Mb. In other words, a server with 512Mb RAM could barely cope with 5 concurrent Apache processes before entering "thrashing hell". And this is without looking at what the database is doing at the same time, often on the same server.
Another side-effect of module bloat is execution times: in one case examined by 2bits, a total page execution time of 1150 ms was shown to to be consumed mainly by loading modules (around 860 ms), with 43 ms being taken up running 175 database queries. Unfortunately for Drupal, 2bits benchmarking shows that Drupal in general has become progreesively slower over versions 5, 6 and 7. Drupal 7 is between 30% and 60% slower than Drupal 5, depending on which caching regime is used to manage the problem.
2bits provide the following advice for speeding up a Drupal site: avoid shared hosting and use a VPS or dedicated server, install as much memory as you can afford on the server, employ one or more types of caching including a database query cache, and avoid using too many modules. In other words, the only way to get good performance out of a Drupal CMS is to run it with as much memory and caching as possible on it's own server.
This article does not mean to single out Drupal, it is merely an example of a wider phenomenon and many similar web applications built on a similar platform (LAMP) suffer from similar problems to one degree or another. The point is that the resource usage of web applications is a real issue, especially when scaled horizontally to include thousands if not millions of websites. With figures like those quoted above, it is easy to see how inefficiency and poor performance can readily translate into the necessity to commission more hardware and consume more electricity powering and cooling that hardware.
So, what is the solution? Significantly, 2bits points us in this direction:
"For a large Drupal site, one of the biggest performance boosts one can do is to install an op-code cache/accelerator ... Since PHP is an interpreted language, every page access has to load the script, parse it, compile it into op-codes, then execute it. This load/parse/compile cycle can add up to a lot of processing time, specially when you have lots of page accesses. Op-code caches/accelerators eliminate this load/parse/compile time, by doing so once, and keeping the compiled version of the script in memory (or disk) and use it next time a page requests this script. This has two main benefits:
- Page processing times can be much less in many cases.
- Decreased load on server resources, mainly CPU time and memory consumption, which is important for a large site
... These are compelling reasons to use an op-code cache."
In other words, pre-compiled code. As web applications become more numerous, more complex, and are required to do more, quicker, in greater volumes, the case for efficient code (C++) running on a more efficient platform (Nginx) is becoming clearer.
References
http://2bits.com/articles/server-indigestion-the-drupal-contributed-modules-open-buffet-binge-syndrome.html
http://2bits.com/articles/tips-on-speeding-up-your-drupal-sites.html
http://2bits.com/articles/high-php-execution-times-drupal-and-tuning-apc-includeonce-performance.html
http://2bits.com/articles/performance-benchmarking-drupal-512-drupal-66-and-drupal-7x-we-are-getting-slower.html
http://2bits.com/articles/php-op-code-caches-accelerators-a-must-for-a-large-site.html