You are here

Drupal

Drupal vs Joomla: hosting costs

Sun's new Fire T1000 and T2000 servers are much touted for their low power consumption. According to the Sun Fire T2000 power calculator, an idle Sun Fire T2000 with 4 cores and 8GB of memory consumes 203 watts, and a busy one consumes 251 watts, resulting in a difference of 48 watts.

Now, hosting companies pay something like one dollar per month in power and cooling costs for every 6 watts of power used. Thus, a Sun Fire T2000 costs 33.83 USD per month (203 watts divided by 6.00 watts/USD/month), and a busy one costs 41.83 USD per month (251 watts divided by 6.00 watts/USD/month).

Imagine that you have one such machine for your Drupal website and one such machine for your Joomla website. Now, say that the Drupal website is on average 100 times more efficient than the Joomla website (a theoretical example) and that the Drupal machine's workload is 0.8%, while the Joomla machine's workload is 80%. That means that the monthly cost to power and cool your server is 33.90 USD per month (203 / 6 + (0.008 * 48 / 6)) for Drupal and 40.23 USD per month (203 / 6 + (0.8 * 48 / 6)) for Joomla.

In this simplified and hypothetical example, you save 6.33 USD per month by choosing Drupal over Joomla, or 75.96 USD per year! Three years will save 227.88 USD. ;-)

That, and Greenpeace will love you! (Greenpeace UK, by the way, has chosen Drupal as their platform of choice.)

30 days to Drupal festivities

In exactly 30 days we'll kick off DrupalCon Brussels. DrupalCon will host over 30 talks and tutorials by outstanding members of the Drupal community. It is a service for the Drupal community, by the Drupal community, and is open for everyone to join.

Drupalcon brussels timeline

Furthermore, I'm speaking at EuroOSCON, we'll have a Drupal booth at EuroOSCON (we're an exhibitor taking part in their "Dot Org Day") and many of us will camp out at GovCamp Brussels and BarCamp Brussels.

If you want to join us, make sure to register for each of these events.

Responsible maintainers

When a popular Drupal module is not maintained properly, it creates all kinds of problems: people can't upgrade their websites, they have to backport security fixes, etc. As a result, the Drupal community has a strong desire to make sure that important modules are always stable and up-to-date. In practice, however, this isn't always the case. Sometimes, important modules are slow to be upgraded, or have stopped being maintained altogether.

It is remarkable how many people think Drupal will never quite manage to realize its full potential unless we make sure that important modules continue to work. I don't necessarily share this belief. However, if some people think that this part of the Drupal development model is broken, we have to try and fix it.

Now, some people demand that we force developers to help fix and upgrade the most important modules in a timely manner. That is, of course, fundamentally flawed ...

You need to realize that if you created a Drupal module that thousands of people depend upon, you created a successful Open Source project. Successful Open Source projects need responsible maintainers in order to sustain. As the maintainer of your project you are in charge, and you have to take responsibility. Period.

We can't force volunteer developers with no particular interest in your module to help you maintain it, nor can we hold them to deadlines. Open Source is all about letting people scratch their your own itch and having good ol' fun. Clearly, there is no fun in being told to upgrade someone else's code by a specified time. Plus, assigning more programmers to a project running behind schedule will make it even later (The Mythical Man-Month).

This is an organizational problem. We can't solve it with a technical solution. So what to do instead?

Well, we have to accept and acknowledge the fact that a project the size of Drupal is always going to be a bit broken, and that command and control won't cultivate the Drupal wilderness. Drupal got built by people who chose to build it, not by people who were forced to. Rather than forcing people to do something, we need a culture that uses peer pressure to encourage responsible maintainership.

For starters, an important Drupal project should not depend on a single person, especially if that person is a busy one. If you are the author of a successful project, you have to delegate responsibility and provide leadership and structure for others to help you. Avoid being a bottleneck. Avoid being a single point of failure.

In order to make your project sustain, you have to make sure that it scales and that you build a team of passionate users and developers. You have to find, motivate, guide, and empower people to take on a role within your project. You have to help others help you.

Anything else is a failure of leadership. It doesn't mean that you are a bad person or that you lack leadership skills -- it might simply be the case that you are too busy or that you have no particular desire to support your project's growth -- but it is a failure of leadership nonetheless.

As a community, we have to make sure that we have the right people at the right place. The people who maintain popular Drupal modules should invest enough time and energy in these projects, and they have to make sure that there is enough programmer effort available to help fix and upgrade these modules in a timely manner.

And me? All I can do is help create the right environment by providing the tools required to build a successful community around your Drupal project, by providing enough time to upgrade your modules and by cultivating the right culture. What I absolutely must do, is debunk the myth that forcing hordes of volunteer developers to rescue you will provide a sustainable solution.

Drupal vs Joomla: performance

Which content management system is faster? Drupal or Joomla?

Experimental setup

I used the "Apache, mod_php, PHP4, APC" configuration from previous benchmark experiments to compare the performance of Drupal and Joomla on a 3 year old Pentium IV 3Ghz with 2 GB of RAM running Gentoo Linux. I used the following software: Apache 2.0.55, PHP 4.4.2, MySQL 4.1.4, Drupal 4.7.3 and Joomla 1.0.10.

I simply downloaded and installed the latest stable release of both Drupal and Joomla, and tried my best to make them act and look the same. To do so, I enabled the login form and the "Who's online" block. I also setup two links and a search widget in the top menu, enabled the hit counters for posts, and setup identical footers. Next, I created one author, one category and one post as shown in the images below.

Drupal post
Joomla post

Apache's ab2 was used to compute how many requests per second both systems are capable of serving. The page was requested 1000 times with a concurrency of 5 (i.e. ab2 -n 1000 -c 5). To test the impact of gzip-compressing pages we specified whether ab2 can accept gzip-compressed pages (i.e. ab2 -n 1000 -c 5 -H "Accept-Encoding: gzip;"). Note that ab2 did not request any images or CSS files; only the dynamically generated HTML document was retrieved.

Requests per second

Drupal vs joomla rps

When caching is disabled Joomla can serve 19 pages per second, while Drupal can serve 13 pages per second. Hence, Joomla is 44% faster than Drupal.

However, when caching is enabled Joomla can serve 21 pages per second, while Drupal can serve 67 pages per second. Here, Drupal is 319% faster than Joomla.

In other words, Joomla's cache system improves performance by 12%, while Drupal's cache system improves performance by 508%.

It is important to note that Drupal can only serve cached pages to anonymous visitors (users that have not logged on). Once users have logged on, caching is disabled for them since the pages are personalized in various ways. Hence, in practice, Drupal might not be 319% faster than Joomla; it depends on the ratio of anonymous visitors versus authenticated visitors, how often your site's page cache is flushed, and the hit-rate of your Drupal page cache.

Lastly, when serving gzip-compressed pages Drupal becomes slightly faster compared to having to serve non-compressed pages. Joomla, on the other hand, becomes a little bit slower. The reason is that Drupal's page cache stores its content directly in a compressed state; it has to uncompress the page when the client does not support gzip-compression, but can serve a page directly from the page cache when the client does support gzip-compression.

Document length

Drupal vs joomla length

The first figure shows that the cost of compressing or uncompressing pages is neglible. The second picture shows that it can, however, have significant impact on the document length, and hence, on bandwidth usage.

Drupal always attempts to send compressed pages. Joomla, on the other hand, doesn't compress pages unless this option is explicitly turned on.

DrupalCon Brussels

Good news! The next Drupal conference (DrupalCon) will take place on September 22nd to 23rd in Brussels (Belgium), alongside Euro OSCON 2006, GovCamp 2006 and BarCamp Brussels. We setup a conference website at http://drupalcon.org/.

Now the dates are set and the venue is confirmed, we're ready to accept presentation proposals and registrations (and looking for additional sponsors).

Whether you are a Drupal professional or an enthusiastic user coming to find out more, we encourage you to join us in Brussels, and to rock out with the smartest Drupal developers, the best Drupal evangelists and top-notch Drupal consultants.

If you want to capture and absorb the passion and enthusiasm behind the Drupal project, this is the place to be. Ideas will fly back and forth. Knowledge will be shared. The Drupal Kool-Aid will be passed around, and the secret Drupal handshake will be taught.

Hedgehog on the walk

Hedgehog on the walk
I was in Italy last week to attend the International Summer School on Advanced Computer Architecture and Compilation for Embedded Systems when I bumped into this Italian hedgehog on my way to breakfast. (HiPEAC, the organization behind the summer school is using Drupal for their website.)

The pain before the pay-off

Invariably, breaking programming interfaces creates a lot of pain, and the habitual willingness to change Drupal's programming interfaces is routinely identified as one of the main issues with Drupal.

For example, rewriting Drupal's form handling from Drupal 4.6 to Drupal 4.7 broke hundreds of contributed modules. And when it turned out that updating those modules was a much bigger effort than anticipated, hell broke loose. It led to quality problems, made release dates slip significantly and hordes of frustrated users were unleashed.

Today, two months after the Drupal 4.7.0 release, Drupal developers around the world are slowly recovering from the pain. We're not quite there yet but more and more people assert that the pay-off is huge and that they are thoroughly enjoying themselves with the new possibilities.

So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off.

Pages

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.