The minimum response time metric (rather than, say, average response time) does a good job of describing whether a web site feels slow or snappy. Below are two pictures that illustrate how the mighty Drupal 6 is inferior in this respect to the much simpler Website Baker CMS. These measurements were taken for a typical web page filled with some images and a moderate amout text in case of Website Baker, and on an almost empty page for Drupal 6 with an installed Ubercart (shopping cart) suite of modules (with no caching). KCachegrind was used for visualization:
Also compare the number of "boxes", which reflect nested procedure calls in both cases.
Does it mean that given a choice you should use Website Baker instead of Drupal? The answer obviously will depend on the required features. The main insight here is that this overhead is very unlikely to go away in the future. It arises from Drupal's overall architecture involving interactions among many small modules, most of which are contributed by third parties and neither explicitly tested nor certified for performance. While offering lots of functionality and extensibility out-of-the-box, Drupal puts much strain in terms of the required quality assurance on the application designer - with performance being just one aspect of the challenge.
Update 2011/01: the latency of rendering simple pages apparently got even worse in Drupal 7 (see comments to this article). I'm aware that it is rather easy to boost Drupal performance for anonymous, non-targeted content several orders of magnitude just by using a reverse proxy cache and so reduce response time to equal network latency. However, I doubt that an average small Drupal site would be able to configure and deploy such optimizations.
Update 2012/03: the poor performance of Drupal is further exemplified by this piece of anecdotal evidence: I have a site which spends just 300ms per request in the database layer and over 6s on the PHP side, in the theme layer, doing usorts, unnecessarily shuffling CCK metadata etc. There is no single obvious bottleneck that can be identified by profiling. The performance is lost practically "everywhere". The only real option is aggressive, coarse-grained caching, but this is rather hard for sites that contain highly dynamic content and haven't been architected from the start to work around Drupal's design deficiencies.
Posts
5 comments:
I read this yesterday and have been thinking about this for a bit. Is Website Baker a CMS setup specifically for ecommerce? Does Website Baker have its own specific ecommerce modules plugged in (or however this CMS works) like you had enabled Drupal's modules? Does Website Baker have modules? How old is Website Baker? Is Website Baker built on PHP, what version? Have you considered running your test against a more optimized version of Drupal (Version 7) where some of the major functionality provided by the best third party modules is now integrated with core? I am not sure based on your pictures and brief description that this analysis is truly accurate or definitive.
Is this website built with Website Baker?
I think you misunderstood my post. I don't compare the merits of Website Baker vs. Drupal for building ecommerce sites. I just commented on the difference in response times observed for an almost empty page, and on the reasons for this difference. My general conclusion is that the Drupal architecture introduces a significant overhead, so if you want to have response times smaller than 100 ms, Drupal is out of question (unless you put some aggressive caching in front of it, which may be very difficult for non-anonymous content). The argument is not so much in favor of Website Baker (I guess you could substitute any small CMS for it) as an argument against Drupal. Pointing to Drupal 7 as a possible improvement has little credibility. People used to point to Drupal 5 when Drupal 4.x was around, then they used to point to Drupal 6, now you can point to Drupal 7... Once again, I'm not saying "don't use Drupal" (I do). Just noting that if you use Drupal, you shouldn't expect lightning fast response times.
I am trying to understand your comparison then. And my comment in regard to core still stands because it "is" being optimized and core developers do realize that it needs to be leaner and more efficient in loading, etc. I will agree that there are significant gains that are lost because of the architecture, the database calls alone are astronomical.
The emphasis of the post lies on the "why", not so much as on the "slow". I have another example which explains the same concept rather well. I've been using the Eclipse IDE for many years. In the beginning (version 2.0) I was having serious doubts about the future success of Eclipse because of its appalingly long startup times (you have to restart Eclipse quite often when developing plugins, so I figured it was a major impediment to the platform's progress). Of course, what happened is that hardware got faster, Eclipse succeeded, and the startup time was somewhat shortened in the following versions. Quite possibly it could even be accelerated further today by replacing a traditional hard disk with a solid state disk. However, the fact that the startup time "problem" has remained visible, and that it cannot be really optimized away by profiling alone - there is no single bottleneck, rather it's an "architectural" issue. I predict the same is going to happen with Drupal - it is going to remain "slow" forever in comparison to leaner frameworks, but as with Eclipse, the functionality benefits and the community around it are not enough to sustain it.
As for the infamous heap of database queries in Drupal, it is true, but their performance impact seems negligible - at least for the response time on an idle site, as measured in this article. Try measuring some day how much time is spent in total in the database - it's a small fraction of the execution time. This is why I didn't post the number of queries rather than kcachegrind PHP call trees. Perhaps I should try with PHP op code caching next time.
good points and they are well taken. thanks.
Post a Comment