PHP

In a previous article from over 5 years ago, we advocated the use of Apache MPM Worker Threaded Server with fcgid over Apache's mod_php.

That was for serveral reasons, including faster handling of static files by Apache threaded server, and lower memory utilization since PHP is not embedded in every Apache process.

However, there were some drawbacks, mainly that APC opcache cache is not shared, and each process has to have its own copy.

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

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!

The latest Long Term Support (LTS) release from Ubuntu has been with us for a bit over a month now, and I love it so far, on my laptop. This is Lucid Lynx 10.04, and will be supported until 2013 on the desktop, and more importantly, until 2015 on the server.

My servers are still on 8.04 though, the previous LTS, for good reason. 10.04 has PHP 5.3. While this is generally a better PHP, it has some compatibility issues with many Drupal, mainly for contributed modules, but some in core as well.

The long term solution to this is to find all PHP 5.3 compatibility issues and fix them in the code. This is a lengthy process though, and will not happen overnight.

So, in the meantime, there are several solutions for running PHP 5.2 on Lucid, some better than others.

In this post, we examine the different approaches, and the merits of each.