Drupal sucks less

All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Almost a year later, I still think that Boris nailed it. We have a long way to go if we want to make it easy for (non-technical) people to create and maintain advanced websites.

Drupal meet-up at Zeitgeist

Zeitgeist

Liza Kindred (Lullabot) kissing the skull that marks the entrance of Zeitgeist, a biker bar that hosted the San Francisco Drupal meet-up. Not the most classy place for such meet-ups but I had a great time talking to the 40-50 Drupal people that showed up. Thanks for all the fun (and the Drupal feedback)!

Drupal meeting at Teh Space

Drupal meeting at teh space

Good food, beer and Powerbooks at the nightly Drupal meeting at Teh Space, a collaborative workspace in San Francisco. Attendees were Earl Miles, Jeff Robbins (Lullabot), Neil Drumm (Advomatic), Boris Mann (Bryght), Kieran Lal (CivicSpace) and myself. We talked about the install system, the Drupal administration pages and thinkered about Drupal's future.

Anchovy

Anchovy

Jeff Robbins (Lullabot) showing off his anchovy at the Korean BBQ.

BarCamp San Francisco

Barcamp San Francisco

When we arrived at <a href="http://barcamp.org/">BarCamp San Francisco</a>, <a href="/album/san-francisco-2006/harry-slaughter">Harry Slaughter</a> was doing a presentation on <a href="http://drupal.org/">Drupal</a>.

Jeff, Boris and me

Jeff boris and me

Jeff Robbins (Lullabot), Boris Mann (Bryght) and myself after our Drupal meeting with <a href="http://spikesource.com/">SpikeSource</a>.

Drupal's database interaction

I used XDebug to profile the behavior of Drupal, and to study the interaction with the database server. I aggregated the profile information of 100 requests to the main page using the "Apache, mod_php, PHP4, APC" configuration used for previous benchmark experiments. More information about my experimental setup is available at that page. XDebug generates a trace file with all the profile information which I visualized using KCacheGrind.

Drupal has a page cache mechanism which stores dynamically generated web pages in the database. By caching a web page, Drupal does not have to create the page each time it is requested. Only pages requested by anonymous visitors (users that have not logged on) are cached. Once users have logged on, caching is disabled for them since the pages are personalized in various ways. Because this represents two different modes of operation, I investigated Drupal's behavior with and without page caching.

With page caching

Critical functions (with page caching)

This figure shows how much time is spent in each function when page caching is enabled. The functions are sorted by the 'Self' column, which shows the time spent in each function without the time spent in its children. The second column shows how often the function was called to serve 100 requests to the main page.

We observe that more than 45% (14.37% + 14.18% + 8.9% + 5.54% + 2.9% + ...) of the execution time is spent in the database related functions. Sending the SQL queries to the database server and waiting for the results takes 14% of the total execution time. Drupal preparing the queries (eg. database prefixing, sanitizing the input to prevent SQL query injection, etc) takes more than 31% of the total execution time. We should look into optimizing the functions that prepare the queries (db_query(), _db_query and _db_query_callback()).

The figure above depicts that PHP's mysql_query() function is called 1401 times. This means that we need 14 SQL queries to serve a cached page. This is where these SQL queries come from:

Queries (with page caching)

This figure shows the Drupal functions responsible for querying the database when serving 100 cached pages. The first column shows how much time is spent in the calls to <code>db_query()</code>. The second column shows how many times each function queried the database and the last column shows the functions' names and source files.

Without page caching

Critical functions (without page caching)

This figure shows how much time is spent in each function when page caching is disabled. The functions are sorted by the 'Self' column, which shows the time spent in each function without the time spent in its children. The second column shows how often the function was called to serve 100 requests to the main page.

When the page cache is disabled, we see that on average we need 144 SQL queries to generate the main page. That is a lot. We also observe that 25% of the total execution time is spent in database related functions: 13% of the total execution time is spent executing queries, and 12% of the total execution time is spent preparing the queries. This is where the SQL queries come from:
Queries (without page caching)

This figure shows the Drupal functions responsible for querying the database when serving 100 pages. The first column shows how much time is spent in the calls to <code>db_query()</code>. The second column shows how many times each function queried the database and the last column shows the functions' names and source files.

Pages

© 1999-2015 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.