Articles

A client with a Drupal web site that is growing too fast asked us to assist with performance problems they were experiencing. Pages would take too long to load.

Upon closer examination, we saw that certain pages were taking up to 6 seconds to load. Using the devel module we found the following picture:

Executed 314 queries in 3198.5 milliseconds. Page execution time was 6280.94 ms.

This means that the database was bogged down, and there is some overhead in PHP as well.

Here is a case study where a module caused extremely poor performance on a site with heavy traffic.

Background

A client with an ever growing site contacted us for some emergency diagnosis and tuning. The site took a long time to respond, and it was not showing any pages to visitors

Diagnosis

Upon investigation we found that the node table has 27007 rows, while the term_node table has 126419. Not specially huge, but still sizeable.

This article is about an anomaly that I have seen on a busy Drupal site. It is related to the network stack.

Normal load

On a normal weekday with the regular load on the peak hours, netstat shows the following:

# netstat -ant | grep ":80 " | wc -l
4833 

While Apache top shows we are at 80-90 requests per second:

Kevin Millecam of Web Wise Solutions has a great introductory article in the Userpoints module.

The article details how one of his clients, Altiris, uses userpoints as a community participation tool, and a reward program program complete with a catalog.

This is a great use case for userpoints, and one that is unconventional too.

In a previous article, I described the "open buffet binge syndrome" where sites overconsume contrib modules, and gave examples where Apache memory was more than 100MB per process.

Today, I tried to take that further, and trace where this memory is consumed and by which modules. This lead to several interesting tangents.

Here are the slides for both presentations that were done yesterday at Open Craft's offices in Cairo, Egypt.

The bulk of the presentation was for the Drupal performance tuning and optimization, which took about 3.5 hours, and there were lots of interaction from the audience.

Recently a client needed to have a mini form for creating specific types of nodes on the fly from anywhere on the site. So, instead of the user clicking "Create content" then "foo" then filling in the form, then clicking submit, a form for that type of content will be shown on most pages in a block in the side bar. So, they can create that type of node quickly.

There are two ways to do this:

Sometimes, you are trying to find a bottleneck in Drupal, and after broadly knowing where the problem might be, you reach a point where you want to benchmark something specific and granular.

For this kind of benchmarks, you can write a standalone script and run it from the command line.

For this you need PHP to be available in CLI mode (Command Line Interface) on your platform.

Here is an example to benchmark the impact of converting the node table from MyISAM to InnoDB.

A site we worked on wanted to have the thumbnails for image nodes to be included in the RSS feed, so subcribers can get a preview of what the image is like before clicking.

So, using the 'rss item' $op to hook_nodeapi, we were able to do this in a relatively simple way, with no need to modify either Drupal's core nor the image module.

This article applies to Drupal 5.x, but may also be adapted to 4.7 and 6.x.