Three months to code freeze - what can we do to make Drupal 7 the fastest release ever?

Nathaniel Catchpole

on

May 29, 2009

Three months to code freeze - what can we do to make Drupal 7 the fastest release ever?

A couple of weeks ago I did some comparison benchmarks between Drupal 6 and Drupal 7. They showed that for most requests in Drupal 7, we've reduced the number of database queries issued significantly, but we're spending a lot more time in PHP. So good and bad news. There's still some more patches pending to reduce database queries per page, but most of the obvious ones are dealt with now. We're loading most pages in Drupal 7 with half the queries than Drupal 6 used, in some cases a lot less. Since this hasn't translated into better performance overall (although it might be easier to scale since MySQL is usually the first bottleneck most sites hit), we need to look elsewhere for gains. There's three main areas where there's both potential to get patches committed before code freeze, but which also need a lot of concerted effort if we're going to get them done in time: 1. Loading less code. The registry in Drupal 7 allows for lazy loading of classes and hook implementations, but we're not taking advantage of it yet. However Daniel Kudwien has done some very nice work moving that issue along, something which should produce significant CPU and memory gains on hosts which don't run opcode caches. That patch currently requires a few fixes elsewhere - so please review http://drupal.org/node/471278 if you can. 2. Unindexed queries There are several places in core with unindexed queries - where WHERE and ORDER BY are run across joined tables, causing filesorts and temporary tables. The tracker 2 module has replaced core's tracker module on Drupal.org. This takes the approach of building a single table which combines data from tables which would otherwise be joined and cause filesorts and temporary tables when resolving WHERE and ORDER BY clauses). A single 15-30 second query can then be reduced to a couple of milliseconds to retrieve the IDs, after which the data which needs to be displayed can be loaded cheaply too. The core patch needs updating, but it would also open the way for a more generic approach to this issue. The materialized view API is running on Drupal.org to improve forum and taxonomy queries, but hasn't seen much review yet, you can currently see it here. 3. Caching. In Drupal 6 we made significant improvements by introducing block caching, and allowed for file and memcache backends to be used without patching core. However block caching went in quite late in the cycle and there are still some TODOs. Some are dealt with by blockcache_alter in contrib. We also need to resolve the issue of block caching when node access modules are enabled - a quick fix for Drupal 7 and possible backport to Drupal 6 is in the issue queue. However to properly respect node access without bloating cache tables we probably need something like Owen Barton's per user caching to enable this without configuration. Much more drastically, Moshe Weitzmann came up with a way to cache rendered content within drupal_render(). It looks likely we could replace the current block caching mechanisms with that, then refactor the main $content block so it could take advantage of it (although probably not cached by default in core - like block caching it's most effective when configured on a per-site basis). I posted some very rough numbers at cyrve which suggest we could see between 50-90% improvement in time per request using this - which would make serving cached pages to authenticated users very close to our anonymous page caching. This is really exciting stuff, but still in the early stages. For page caching, while it remains very well optimized, Dries just indicated he'd consider some basic file caching in core for Drupal 7 - and we have a mechanism on that issue which simplifies some of the issues with providing file caching from contrib. There's not a great deal of time to get all these changes in, but a combination of these could see Drupal 7 performing at least as well as Drupal 6, and potentially much faster for authenticated users on both cheap shared hosting and large deployments. This isn't a comprehensive overview, but if you're dealing with performance issues in Drupal 6 and been wondering if there'll be any help in Drupal 7, now's the time to get stuck in.

Share it!