Informative articles on various technologies ...

Beware of Drupal modules that disable the page cache

When doing performance assessment for large and complex sites to assess why they are not fast or scalable, we often run into cases where modules intentionally disable the Drupal page cache.

Depending on how often it happens and for which pages, disabling the page cache can negatively impact the site's performance, be that in scalability, or speed of serving pages.

How to inspect code for page cache disabling

Admin Menu module: Popular yet occasionally problematic

We encounter this problem a lot: the extremely popular and oft-used Admin Menu module causes performance problems.

Here is an example from a site we recently did a Drupal performance assessment for.

Executed 3,169 queries in 584.11 milliseconds.
Page execution time was 4,330.86 ms.

As you can see, the number of queries per request is horrendous, and the site is a resource hog if left in that state.

Drupal site excessive memory usage traced to APC and php5-memcached

We were recently troubleshooting a client site running Drupal 7.x, and main complaint was high memory usage on all the site's pages.

We were able to diagnose and solve two main causes that range from the common to unusual.

This is a Drupal 7 Commerce site with 173 modules, and 3 themes enabled. Apache Solr is used for search, and there is custom code to talk over the network to a non-Drupal backend server.

The site runs on a Debian Squeeze Xen VPS.

For most of the site's pages, the client was seeing high memory usage, as follows:

Problem: high memory usage

Presentation: HUGE! A Drupal site with 381 modules, 174GB MySQL database, and 200 million row tables

Here are the slides from my Drupal Camp Toronto 2012 session.

The site is ScienceScape.org, a repository of scientific research going back to the 19th century, down to the latest biotechnology and cancer release.

Update: You can watch a video of the presentation on Vimeo.

Memory usage revisited: when the Open Buffet is not to blame, rather Views

We have written before about Drupal Memory usage by modules, and the Open Buffet binge syndrome.

But this time, it was different. Modules were not to blame.

While inspecting a site that had several performance problems for a client, we noticed is that memory usage was very high. From the "top" command, the RES (resident set) field was 159 MB, far more than what it should be.

We narrowed down the problem to a view that is in a block that is visible on most pages of the site.

Drupal not saving admin pages with large number of input fields

Do you have a problem with some Drupal admin pages with a large number of input fields not saving? Does the page just returns back with no message confirming that changes have been saved?

Well, this happened recently on a site that we were troubleshooting for a client.

The symptoms were: trying to save has lots of input fields, a) comes back with no message about saving changes, and b) the values changed were not saved.

The site had 210 enabled modules, 14 user roles defined, and 84 content types, with 76 content fields!

Yet another Denial of Service (DoS) attack

We recently wrote on a botnet attack hammering web site causing outages.

In the past few days, we have seen another Denial of Service attack on a client's site.

The symptoms were a complete outage of the server, with very high CPU usage, and high load average (over 900 in some cases!).

Upon investigating, we found that this is caused by the following hits:

75.145.153.237 - - [22/Jul/2012:19:55:07 -0400] "POST / HTTP/1.1" 500 539 "-" "-"

Botnet hammering web site causing outages

We had a site for a client that was stable for close to two years, then suddenly started to experience switches from the master to the geographically separate slave server as frequently as twice a week.

The site is an entertainment news site, and its articles get to Google News on occasions.

The symptoms was increased load on the server, a sudden influx of traffic causing over 800 simultaneous connections all in the ESTABLISHED state.

Pages

Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting