Drupalcon Highlights: Performance, Testing, Kittens

First, if you aren't at Druaplcon this year, recordings of most (all?) off the sessions are available online! I've even bookmarked several that I couldn't attend, but want to watch later.

Here are some highlights:

Performance in Drupal 7

There's a lot of neat stuff going into Drupal 7 to keep things fast. Catch gave a great overview at Performance in Drupal 7.

  • Multiple loading is available for fetching batches of objects, via functions like node_load_multiple(). This helps avoid the n+1 selects problem.
  • A cookie is set to distinguish anonymous users from logged in users. This allows the page cache to bypass the session table when the cookie is present, and serve cached pages quicker. It's also a big help if you're using a reverse proxy like Squid or Varnish.
  • Profiling reveals some big surprises — for example format_date() is really, absurdly expensive. Work is being done to improve this. It's also a great example of why profiling is so important, and how intuitions about performance are usually wrong (who would ever suspect such a harmless little function?).
  • Some experimental work is being done with hierarchy loading, such as vocabularies. Some nifty math allows a nested set to be keyed with a rational number. An items children can then be fetched with a simple range select.

Not all of these ideas have been committed yet — if you're interested check out the performance tag on the D7 issue queue.

Another vital tidbit I wasn't aware of — the system cron task clears all caches. So if you have a high cron frequency, you really need to set a minimum cache lifetime.

Test-Driven development

The automated patch testing system has been huge for Drupal's development process. The future of this framework was discussed at Saving webchick time:

  • Support is being planned for including tests that are known to fail. I really like this approach because a test that demonstrates a bug will be able to be committed even before the bug is fixed. Writing tests first (before implementing a new feature) can also serve as a specification of sorts, and also keep development focused on solving the immediate problem at hand.
  • Some scripts are being developed that will allow anyone to volunteer a test server. This is great because with more servers we can have faster turnaround times.
  • Testing various configurations is in the works — most importantly Postgres and SQLite. The idea of doing parameter sweeps of many different configuration permutations was discussed, though the feasibility of this idea is unclear.

If you run into Boombatower, be sure to say thanks for the PIFR infrastructure! It's easy to complain when your patch doesn't get the test result you want (I've been there), and when the bot was first introduced it did cause some disruptions. However the effectiveness of this process was demonstrated during the latest usability test, when only two actual bugs were discovered by the testers!

Save Kittens!

Now you're killing fake kittens instead of real kittens at the cost of a couple arrows. — Crell, on Objectifying Drupal. Sorry, you're just going to have to watch the video.

kitten

Tagged as: Drupal, Drupalcon, fake kittens, performance, pifr, Test-driven development