Drupalcon Szeged

I made it back from Hungary last Friday, and am only now starting to convince my body that it really isn't 9 hours later than it is. After Drupalcon, I managed to make it out to Eger, for castles and a valley of wine cellars (thanks for the recommendation Chrys). Following Eger I returned to Budapest to explore more castles, a Cold-war-era statue park, and some labyrinths all made possible by some of the best public transit I've experienced.

Being back, and having had a bit of time to process all that I took in at Drupalcon, I wanted to do a bit of a review of some of the highlights. For most of the talks I mention below, there are either slides, video or both available here.

The venue and organization

The venue itself was very nice. Spacious and airy, it was the perfect place for Drupal geeks from all over the world to congregate and talk about, well, Drupal. Also, many thanks to all the volunteers and the Hungary Drupal community that made Szeged a reality.

I can't talk about the venue and the organization of the event without at least mentioning the Hitchhiker's Guide to the Galaxy theme. I won't go into too much detail, as the pictures do that, but suffice to say I thought it was awesome and thorough (42+ languages, a babelfish, don't panic and the certainty of knowing where one's towel is).

The State of Drupal

Dries, while opening the conference with his State of Drupal talk, hit on many aspects of the future of Drupal.  One highlight was the idea of embracing RDF, which not only makes for richer content, but addresses the problem of importing and exporting for Drupal in an application-independent manner. Another very interesting point was that most Drupal developers feel they are best at HTML, and by the same token, want to learn about HTML the least. That's good I suppose...

Drupal 7 preview

Many of the sessions I attended provided a very exciting preview of Drupal 7, and I came away with high hopes for the new version.

Larry Garfield proposed the idea of getting handlers into core. My favorite example of why this might be useful was about the idea of swapping out default file handling, for say, a file handler that sends all images to Flickr, and all videos to YouTube, but behaves normally for everything else. To do this without handlers, one would need to either hack core (oh noes), hack image and video modules, or write a custom module. With handlers, the modules can simply be concerned with the Drupal API, thus making this sort of behavior module-independent. Essentially, handlers are one of the last steps towards making Drupal completely customizable without hacking core (thus saving kittens).

The very next day, Larry gave an overview of the new database layer that landed, which takes advantage of PHP's PDO abstraction layer, shortly before Drupalcon. The short of it is that the new abstraction layer looks awesome. The dynamic query builder will take the place of complicated string concatenation and pattern matching that plagues certain hooks and modules today. The new layer also provides—out of the box, so-to-speak—the ability to support master/slave replication and transactions, to name a few. Also, since this is all object-oriented, simple (but fragile) INSERT statements are no longer directly coded into modules. Instead, inserts and updates are built up using placeholders, and can be reused. Finally, the new db_merge() function will make checking for an existing record (in order to determine if an INSERT or an UPDATE is needed) a thing of the past.

Barry Jaspan gave a talk on the Field API that will hopefully be landing in Drupal core for 7 (ie, CCK in core). However, the field API isn't just about moving the CCK module's functionality into Drupal. Along the way, the code will be transformed into a real API (so that the creation and modification of fields is no longer dependant on a form submission). Another key change is the idea that fields will be attachable to anything, not just nodes. During the talk, field definitions looked to be custom classes, which seemed very clean and extendible. It was later rumored around the halls that this idea had been scrapped, but I'm unable to find any hard evidence indicating one way or another.

Peter Wolanin discussed the idea of page rendering being capable of outputting many different formats in Drupal 7. The central idea of the talk was to move page rendering to a later stage in the process, so that data can be rendered as, for example, JSON, XML or XHTML, depending on any number of factors. The only way to currently change format, is to either pre-empt the rendering level (by exiting the script early) or to re-render data, which is inefficient at best. Needless to say, this would be a welcome change.

And finally, the new file handling patch continues to get closer to RTBC.

So long, and thanks for all the fish

That's all I have time for now, although there were many other very exciting and informative sessions/BoFs (I saw a demo of the progress being made with the Geo module, as well as the work Development Seed is doing with Mapnik, and am very excited about the future of mapping and Drupal).

Today, on the first day of Drupalcon, Rasmus Lerdorf gave a fantastic presentation about PHP, performance, scalability and security. In this talk (the slides are available here), he discussed the writing of frameworks, and how they tend to trade off performance for what might be deemed as cleaner code. After walking through some very cool benchmarking methods (see slides 8, 14 and 16), he proceeded to benchmark some of the more popular PHP frameworks out there (slides 24 through 32). Unfortunately, when it came to Drupal, it was benchmarked without caching enabled. I have duplicated his Hello World module, and enabled it on a clean Drupal 6 install. While the absolute numbers are incomparible due to my local environment being different from his, I have run it without caching

Response time:                  0.38 secs
Transaction rate:              13.10 trans/sec

and then with aggressive caching enabled:

Response time:                  0.04 secs
Transaction rate:             119.42 trans/sec

The performance increases by roughly 9. By applying this ratio to his results for Drupal:

Response time:              0.10 secs
Transaction rate:          51.37 trans/sec

the numbers would be something like:

Response time:             0.0105 secs
Transaction rate:           468.5 trans/sec

With the pure html page coming in at about 610 transactions per second, Drupal 6.4 with aggressive caching enabled (as well as css and javascript optimization enabled) is much closer to that than any of the other applications/frameworks tested for the presentation. Of course, not having the exact same environment as Rasmus, I'm not sure if these results scale linearly, so this is mostly speculative. Even so, it takes Drupal a lot closer to that goal of not killing kittens, and a greener computing world.

Edit:

The above numbers were without APC enabled. With APC, the ratio is more like 5-6, so in that case, Rasmus' numbers would look like this:

Response time:              0.017 secs
Transaction rate:          256.85 trans/sec

While not as good as those above, still these numbers come in very close to the best of the applications benchmarked by Rasmus.

Tomorrow I fly to Budapest by way of Frankfurt as I start making my way towards Drupalcon in Szeged. Brian will be joining me in Szeged closer to the start of the conference. I'll have several days to take in the sites of Budapest (the funicular railway to Buda Castle looks awesome), then catch a train south to Szeged. I'm looking forward to meeting so many Drupal people all in one place, and the sessions are looking fantastic.

I'm particularly excited about the Awesome Testing Party, not only due to the free pancakes, but also, writing tests is a whole lot of fun, and they're critical for a solid Drupal core, and a more feature-rich development cycle.  It also looks like there should be several excellent sessions on the state of GIS, mapping and Drupal (A Roadmap for Mapping: GIS on Drupal in 2008 and Beyond, Simple Mapping Mashups with Drupal, and Mapping with Drupal and Mapnik just to name a few). And of course, no Drupal gathering would be complete without a session about Awesomeness and Drupal.

I'll be posting updates frequently from Drupalcon. Also, if you'll be in Budapest prior to Drupalcon and are interested in any pre-Drupalcon activities, drop me a comment here, or contact me directly.