After spending 3 days trying to get Elipse PDT and the Zend debugger working on Mac OS X, my nerves were very frayed, indeed. Apparently, there has been an ongoing problem with the Zend debugger not stopping at breakpoints on Mac Intel machines...something that has plagued Eclipse through 3 different PHP extensions. (don't even get me started on how crazy it is that Eclipse has seen three completely separate PHP plugins within less than a year)
In the end all was not lost. On the contrary, after enough scratching around Google I discovered what I needed to know. Komodo has become the semi-de-facto IDE of choice for many Drupal developers. A fact confirmed for me when I saw many familiar names from the Drupal community on the ActiveState website (itself a Drupal site).
Suffice to say with Komodo I got local and remote debugging up and running within just a couple hours, and it's been a total dream to use.
So now I have a proper debugger, integrated svn, and last but not least, Drupal api code compeletion/documentation is included. And if that's not enough, it uses 100mb+ less memory than Eclipse did.
Komodo is going to set me back a few bucks ($295) after my trial runs out, but even at that price it's a no-brainer for some who makes their living with Drupal and PHP. Kudos to ActiveState on their outreach to the Drupal community.
Perhaps, one of the most important contributed Drupal projects ever released, was released today (at least as far as professional Drupal development goes).
AutoPilot is out and for anyone who has a Drupal site for which they need to worry about syncing development, staging, and or production versions - it's magnificent. I've had privilege of seeing it work in person - and it's unlike anything available to Drupal developers before now.
Though I haven't set up my own local instance of this yet - the version I saw allowed one to be able to simply click a button in order to update changes between a development environment and a staging/production environment.
Congratulations, WorkHabit on such a valuable contribution, and for everyone else - grab this at your earliest convenience and let's work to integrate this as a core part of a Drupal development toolbox, asap. (ala the devel.module)
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):
2489.69 ms (request time for auth user, no-caching of any kind)
-878.09 ms (request time for auth user, block-caching on)
1,611.6 (difference) / 2489.69 = 64.73% improvement w/ block cache on
With the block caching on, the mean processing time is 876 ms with a sd of 91.9 ms while the base install results in 2481 ms mean processing time and sd of 91.9. Even at the upper end of the standard deviation, the block-cached processing time is 967.9 ms, which is far below the low end of the standard deviation (2080.1 ms) for the non-block-cached test. Looks like a clear improvement - 64.7 percent improvment using just the means.
The benchmarks are posted here so that everyone can do their own math. If you'd like to check the validity of my installation/numbers - feel free to download a tarball which includes all the files and a db dump. Username/pass for user 1 = superadmin
Benchmarks using 10,000 nodes, 5000 comments, 15 categories, 250 terms, 2000 users and with the following blocks enabled:
BLOCKS ENABLED Recent comments User login Navigation Active forum topics New forum topics Who's online
[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.
Recently a client we helped get started with Drupal and admin their backend systems for, had their first 500,000+ unique-visitors day.
Everything went well, the lessons we've learned over the years of Drupal performance tuning (Part I, Part II), combined with well planned Apache/MySQL/PHP settings provided an event-free day (other than watching the hit counter go through the roof!).
Showing that it was no fluke, the site has had numerous 500,000+ days since then and has settled into an average of 150,000-200,000 unique views a day / 6,000,000-9,000,000 visitors a month.
If you have a Drupal site that you need to prepare for high traffic and high availability, give us a shout. We can help you handle it.