Yesterday, I upgraded the PHP version on my server from 5.2.4 to 5.2.5. PHP 5.2.5 brings improved "stability of the PHP 5.2.x branch with over 60 bug fixes, several of which are security related". I also reintroduced eAccelerator back onto the server. I stopped using eAccelerator last spring, not so much because I had any real issues with it, but because I spent the summer months hosting my sites on the cheap.

This time, when I compiled the new version of PHP 5.2 onto my server, I also made the decision to not load the latest version of PHP 4. Although most of the Web applications I run on the server are PHP 5 compatible, I've always made sure I also had access to a version of PHP 4. The time has finally come though where I really don't have a need or desire to host a content management system that is only PHP 4 compatible.

A great article posted on 2bits regarding the use of PHP accelerators: PHP op-code caches / accelerators: Drupal large site case study.  While the article uses Drupal for the case study, the use of PHP op-code caches/accelerators such as eAccelerator and APC should benefit any PHP-based application on the server.

For a large Drupal site, one of the biggest performance boosts one can do is to install an op-code cache/accelerator. PHP op-code caches / Accelerators Since PHP is an interpreted language, every page access has to load the script, parse it, compile it into op-codes, then execute it. This load/parse/compile cycle can add up to a lot of processing time, specially when you have lots of page accesses.  Op-code caches/accelerators eliminate this load/parse/compile time, by doing so once, and keeping the compiled version of the script in memory (or disk) and use it next time a page requests this script.

You'll want to especially take a look in the article at the CPU and memory usage comparisons between using and not using op-code caching.  The writer also hints that eAccelerator may use less CPU and memory usage than APC.  I personally like eAccelerator over APC, but either one is a must have if you run your site on a virtual private server (VPS) or a dedicated server.  I run CMS Report using eAccelerator on a VPS I manage through Dakota Hosting.

Over the weekend, I upgraded the server that hosts CMS Report with the latest stable releases of MySQL and eAccelerator. The upgrade from MySQL 4.1 to 5.0 was easy compared to the upgrade I made a year ago from MySQL 3.23 to 4.1. This time around I also have use of CPanel which meant I could make the database upgrade with at least one eye closed. My journey with upgrading from eAccelerator 0.9.4 to 0.9.5 however took a lot longer.

I've been using eAccelerator 0.9.4 since it was released early in 2006. I've gotten into some trouble in the past by those smarter than me when I tried to explain exactly what eAccelerator does and does not do. To play it safe this time around, I'll give you the summary of what eAccelerator does straight from eAccelerator.net: