News, Articles

Too often when someone asks for a feature "Can Drupal do xyz"? The answer is "just install the whatever module". While this is the correct answer in 90% of the cases, there are other cases where an additional module is bad thing to have.

Performance troubleshooting and tuning of web sites is often, to paraphrase Winston Churchill, "a puzzle inside a riddle, wrapped in an enigma".

One of those puzzles is how sites are put together: in this case: multiple layers of modules that obscure the real cause of where the slowness of a site is, and a theme for the topping.

Problem and symptoms

In some large client sites, we see many queries from the session handling code in drupal, mostly from the sess_write() function in includs/session.inc.

Examples of creating a new session:

INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES ('744e888350d5c759f067d58380f6874e', 0, 0, '10.1.1.1', '', 1243567441)


And examples for updating a session:

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:

A very large site that we manage for a client experienced two instances of outages recently.

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.

Zend have had their own proprietary PHP server product for quite some time now. This week, they announced their Zend Server Community Edition, with the intention to disrupt Java, and grow PHP specially in the current economic conditions.

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.