Articles

One of the most useful features in Drupal is its cron hook. It allows modules to execute stuff at regular intervals when cron.php is run.

This is used for many things, such as indexing new content that was added to the site, cleaning up old watchdog entries and many other things.

In many cases, though cron hooks implemented by modules can cause added burden to a site. This is specially true if you run cron too frequently or too infrequently.

An example for a client came up recently. They are using xmlsitemap, like many sites do.

Many sites need a way to browse content by "previous" and "next" links. For example, a photo gallery site would have the visitor view one image, and then offers links, or thumbnails with links, to the previous node or the next node.

This navigational aid engages the user more, and avoids the pitfalls of them getting lost by a less than obvious multi level navigation scheme.

There are several common ways for doing this "on the fly" via SQL, as in the following articles:

Two very large sites that we manage for clients experienced several instances of outages recently.

On the first site, the symptom was a long running query and many other queries locked as a result.

Upon digging deeper, we found out that this was caused by the taxonomy browser module. This is a useful module for drilling down into a site's category structure for nodes that match certain criteria.

Most of us have heard about the 80/20 rule a.k.a. The Pareto Principle. Simply put: 80% of something have just 20% of the reasons. In other words if you address the 20% of the causes, 80% of the symptoms will go away because of that.

When tuning sites for clients, we often see the usual symptoms and causes of why a site is slow, and occasionally we find an unusual reason.

For one client, after we diagnosed the main reason for a site being slow (bottleneck between database server and web server), they continued to experience slowdowns.

This was getting annoying as it happened several times a day, and their customers were complaining about the slowdown on a daily basis.

A client contacted us for help with a Drupal multi site installation that is experiencing very slow page load times, causing lots of complaints from their user base.

We started by checking the hosting environment, which was two Xen based VPSs, one with 2 GB of memory acting as the web server, and the other with 1 GB of memory acting as the database server.

The site's home page took a total of 10,055 milliseconds, and had 1,060 queries taking 9,327 milliseconds.

The number of queries is on the high side, but what is more troubling was the 9.3 seconds taken by the queries to execute.

A media firm in Germany, jetztdesign GmbH contacted 2bits.com for partnering on an intranet site for a large multinational corporation.

The intranet used a lot of contributed modules, with 35 custom developed modules for this application. It would serve a user base of more than 80,000 employees.

Testing of the application showed that only 30 concurrent users can be active simultaneously, falling well short of the requirement for 200 users to be active at any given time.

As promised, here are the slides from the DrupalCon Washington DC 2009 presentation : Backend Drupal performance optimization and tuning: a guide for everyone.

The slides contains extra information, such as the case studies, graphs and the like.

Again, thanks to Ashok Modi (BTMash) and Jose Carlos Marco for saving the day with converting the presentation after the laptop mishap.

Update May 2013: We no longer recommend fcgid ever since Ubuntu Server 12.04 was released. This is because that version has PHP-FPM, which provides every benefit that fcgid has, with the added advantage of a shared opcode cache for all processes. We will be writing a full article on PHP-FPM with Drupal in the near future (soon to appear at High Performance Drupal with Apache MPM Worker Threaded Server and PHP-FPM).