Thanks to all of those who braved the cold snap and showed up for the Drupal Users Group monthly meeting for January 2009.

This was a case study on a site that was forced to move from a shared host to a VPS, yet was still slow, and how we diagnosed the problem, and found a solution for it.

Here are the slides for the talk, in PDF format.

AttachmentSize
PDF icon Diagnosing and Speeding up a Slow Drupal Site - A Case Study506.55 KB
Articles

Comments

Visitor (not verified)

Fri, 2009/01/16 - 10:50

This was a good read for me, to get an overview of what possibilities there are to work on performance. Thanks!

Visitor (not verified)

Fri, 2009/01/16 - 16:36

Any chance on getting the video or audio recordings from that talk?

Khalid

Sat, 2009/01/17 - 11:09

It is "over use".

This means that there are too many CCK fields, too many content types using them, too many views, too many panels, ...etc.

This causes a lot of database queries and code to be executed on every page, and will slow a site down.

An example: a site that had 19 content types (not in itself very high), but had 99 views and 72 panels, with blocks on every page using many of them.

The site was, as expected, slow.

In moderation, everything is good. Excessive use of anything leads to issues.

Visitor (not verified)

Sat, 2009/01/17 - 09:24

Thanks! Great slides.

Here is my situation. The site is quite "heavy" with 133 enabled modules, panels, views etc.

MySQL cache and XCache are both enabled and the overall performance is good. Got much out of these two caches. But still some pages could be faster.

Site is running on a quite powerfull machine (2.8 GHz Quad-Core Intel Xeon with 8 GB ram)

And this is puzzling me the most. CPU usage never goes above 30% and the site is low traffic. It seems that the system doesn't allocate more resources to apache/php. Can this be? It's an OS X Leopard Server. I tried using renice for the apache processes, but no real result.

Thanks for any feedback on this.

Here are some random results:

Front page (panel + some views blocks etc.):

Page execution time was 2433.05 ms. Executed 1512 queries in 396.11 milliseconds.
Page execution time was 1654.37 ms. Executed 1512 queries in 471.91 milliseconds.

Some other pages:

Page execution time was 442.6 ms. Executed 531 queries in 228.22 milliseconds.
Page execution time was 456.28 ms. Executed 523 queries in 188.85 milliseconds.

Khalid

Sat, 2009/01/17 - 11:20

Seems that your conclusion that the system does not allocate resources to Apache/PHP is kind of hasty. What makes you think so? Is there any data to back it up?

Looking at the front page, the database is taking up a small portion of the overall page time. So it seems XCache is not doing its job, or you have some module that is using excessive CPU or doing network connections.

The other pages seem acceptable with total time under 0.5 seconds.

Visitor (not verified)

Fri, 2009/01/23 - 11:35

The case studies were very useful :) - reading the steps necessary to find out about the problem really helped structure the mess in my mind :D

Many many thanks for sharing your slides !

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting