performance

After struggling with upload/commit transfer speeds that were absolutely crippling, I've finally managed to get an exponential speed boost for svn merging and svn committing large numbers of files.

For svn merging, see this post by the good folks at WorkHabit.org.

For general SVN transfer speed help - hop into your /etc/ssh_config file and add these lines to your file:

Enjoy not seeing upload times of 2k/sec anymore. :-)

The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a client who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.

As a follow up to an earlier article I posted about Drupal 6 performance, and please bear with my learning curve for a moment, I figured out by 'accident', and a lot of investigation, that it matters very much the order one uses when they 'generate content' with the devel module for benchmarking purposes. My previous tests were done incorrectly - I inadvertently created a bunch of nodes that weren't assigned to any terms or users and vice versa. The result of correcting this error means that a no-cache-enabled-baseline takes much longer to complete than when I had things setup incorrectly.

...happily, the point of this article isn't that I'm a total goof.

No, the good news out of this ordeal is that now when block-cache-disabled performance is compared to block-cache-enabled performance the results are MUCH more substantial than previously noted (and thus Drupal 6 is going to be that much faster than it's predecessor Drupal 5 for authenticated users):

[The information in this post has been greatly updated - basically, Drupal 6 will enjoy even more of a performance advantage over Drupal 5 than is indicated here]

The more one learns about Drupal 6 the more there is to like. A while ago, right before Drupal 5 was released, I heard someone reference it being a 'developer's release' (think maybe it was Dries). That seems like an apt way to describe Drupal 6 these days. If the anti-CMS, ya-gotta-roll-your-own-or-it-stinks critics have a last breath left, this might be what snuffs it out once and for all. The list of new features, optimizations, and/or technologies introduced in Drupal 6 seems destined to light up the antennae of developers everywhere.

Performance, performance, performance

If there is any doubt about whether there will be performance improvements for Drupal 6, wonder no longer. Benchmarks, made using these standards, shows that the current, pre-beta, version of Drupal 6 performs 19.5% faster than Drupal 5.2 does when NO page caching is on. A healthy improvement by any standard, but even more so when one considers the following:

• Drupal page caching is never active for logged in users, so any gains to non-cached speeds are pure gains for everyone that is logged in. This is a big deal when you consider that up till now it has taken 10x longer to serve authenticated/logged users than it does to server anonymous site visitors.
• With the block cache patch which looks destined for core applied, Drupal 6 becomes 32% faster than Drupal 5.2 for authenticated users. Community site system admins rejoice.

Without quibbling over the details of specific numbers and/or benchmarking methods - one thing is very clear.

Speed is coming to Drupal.

• Download benchmarks for Drupal 6, which includes benchmarks for block caching here.
• Download benchmarks for Drupal 5-2 here.