Drupal Planet

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.

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 ...

With the "Cloud" being in vogue currently, we see a lot of clients asking for cloud solutions, mostly Amazon AWS. Sadly, this is normally done without really doing a proper evaluation into whether the cost is reasonable, or the technology is suitable for their specific needs.

Amazon AWS provides some unique and compelling features. Among those are: instant provisioning of virtual servers, billing for used resources only, ability to provision more instances on demand, a wide variety of instance types, and much more.

I wanted to take a a few minutes to document how the Drupal community is amazing in how it self organizes to get stuff done ...

One of the projects that I have started a long time is Userpoints. Being mostly an API, it has flourished with a mini-ecosystem around it of userpoints modules for various and quite diverse things.

For Drupal 6.x, I was fortunate to have jredding (Jacob Redding) take the lead and add several new features that he needs for various projects.