News, Articles

Recently a client complained that their site has been suffering from slow downs that were not there before.

Upon investigating the history of resource utilization, we found that memory usage has increased, and at the same time, the load average has increased as well.

To cut a long story short, we found out that initially, the site had neither dblog nor syslog modules were enabled, and they were enabled before the issues started. They started when syslog was enabled.

Together with Alan Dixon of Black Fly Solutions, Khalid Baheyeldin of 2bits.com, Inc. gave a presentation on Web Site Performance, Optimization and Scalability at Drupal Camp 2011.

The slides from the presentation are attached below.

By design, the Drupal CAPTCHA module disables page caching for pages it is enabled on.

So if you enable CAPTCHA for user login and/or registration forms, those pages will not be cached. This is often acceptable.

However, if you enable CAPTCHA for comments, and have the comment form visible at the bottom of each node, then a big portion of your site's pages will not be cached in the page cache at all.

We recently conducted a performance assessment for a client, and the main problem was something really simple, but also very detrimental to the site.

The site used the Service Links module, version 6.x-2.x.

The following are the performance figures for the site, in seconds, before any tuning.

 3.67 http://example.com/product/215
 2.64 http://example.com/product/572
68.32 http://example.com/list1
65.11 http://example.com/list2

Quick Tabs is a widely used Drupal module. Site builders like it because it improves usability in some cases by reducing clutter.

Incidentally, the way this module works has cause us to run across performance issues caused by certain uses. See previous article about Quick Tabs can sure use more caching and a case study involving Quick Tabs.

Aggressive crawlers that hit your web site a lot can cause performance problems.

There are many ways to identify aggressive crawlers, including writing custom scripts that analyze your web server logs.

One tool that we found to be useful in analyzing which crawlers hit the site the most today or yesterday is Go Access.

Getting Go Access

Go Access is available for Ubuntu Natty Narwahl (11.04) only, but not earlier LTS releases.

Earlier today, I presented at DrupalCamp Toronto about 3.4 million page views a day, 92 million per month, one server and Drupal.

As promised, the slides are attached, as a PDF for everyone's reference.

A client site was facing intermittent outages, specially at peak hours.

We investigated the issue over a few days, and narrowed down the cause to certain slow queries, described in more details below.

They had tagadelic on every page, displaying a tag cloud, and from that, crawlers hit every term to paths like taxonomy/term/1581.

Slow queries causing server outage

One great feature that Drupal has is the ability to make modules run certain tasks, often heavy ones, in the background at preset intervals. This can be achieved by a module implementing hook_cron.

Core uses this feature to index new content for the search module, ping module to notify remote sites of new content, fetch new release information from drupal.org, poll other sites for RSS feeds, and more.

Various contributed modules use this for various purposes, such as mailing out newsletters, cleaning up logs, synchronizing content with other servers/sites, and much more ...