Articles

In a recent article, we explained how to build memcached from source and  PHP memcache using PECL on Ubuntu Gutsy 7.10.

This article is a followup on how to configure memcache for Drupal, and how multiple bins help with performance.

Each bin in memcached correspond to one or more cache table in Drupal.

Copying a Drupal site from a live server to a test one is normally a straightforward process: you dump the database, and create a tar archive of the site, extract the archive, load the database dump, make a few changes to the settings.php file, and voila: you have a test site that mirrors the live site. You can then use this for development, training or any other purpose.

Almost every one knows that running high traffic sites powered with PHP applications is impossible without a PHP op-code cache / accelerators. Op-code caches speed up PHP applications by parsing and tokenizing PHP scripts once, and executing them faster for every subsequent request.

There are several accelerators available, many of them are free. The ones that are maintained are:

A large web site that 2bits.com built and manages gets over 1 million page views a day. It has been using Drupal's Memcached API module for several months. The version installed until yesterday was 5.x-1.1. Since there is a newer version (5.x-1.7), it was time to upgrade.

The upgrade seemed to have gone well, but we saw the load on the CPU to go up a lot during peak hours.

Complex PHP applications, such as Drupal, can gain a lot of performance benefits from running a PHP op-code cache/accelerators.

APC, Alternate PHP Cache, is now the most maintained free/open source op-code cache, and is being used more and more as it emerges to be the most stable.

The instructions here detail how to get APC running on an Ubuntu server running Gutsy Gibbon 7.10.

Complex PHP applications, such as Drupal, can gain a lot of performance benefits from running a PHP op-code cache/accelerators.

APC,
Alternate PHP Cache, is now the most maintained free/open source op-code cache, and is being used more and more as it emerges to be the
most stable.

A while back, we need to do display different sized user pictures (avatars) in Drupal 5.x on a client site. They wanted the user picture on the user profile page to be 100x100 pixels, but be displayed only as 25x25 on blog comments.

This is fairly easily achieved by creating this function in template.php. This function creates 25x25 size images from the original 100x100, and takes an argument of size so either can be used in different places.

A question that is often asked in Drupal circles, is how much can a Drupal site scale to, and what is the hardware necessary to make it do that. The answers often go on tangents, with some advocating multiple web boxes, with a reverse proxy in front of them, and multiple master/slave MySQL boxes too, like we have on Drupal.org.

The real answer is : it depends ...

Depends on what? Many things, like:

A recent blog post by Ezra Gildesgame on benchmarking Drupal got me rolling with some code laying around for ages. The instructions provided in the aforementioned article do indeed work, but there has to be a better way for automating benchmarking of Drupal removing the repetitive or manual steps needed.