The Key to ExpressionEngine Performance

Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.

Imagine you were to build a house. After all the years of building web sites and being a slave to “the man” the pay day has finally come; you’ve sold out and you’re finally gonna hire a contractor to design and build you the house of your dreams (or your wife’s/husband’s/whatever’s dreams). You want to get everything; all the bells and whistles anyone could ever want in a house. Doors and windows and all the other house “things”. No expense is spared and it’s gonna be a marvel of engineering to be proud of.

And then you decide to build it on top of a swamp that floods every year with intermittent droughts, earthquakes, tornadoes, and hurricanes, and wasps and mosquitos. And bed bugs. And that really gross smell tanneries have hanging around. That too.

This is what a lot of web developers do. It’s really weird when you think about it too. They spend so much time putting together their project, crafting the perfect solution to whatever problem they’re trying to solve, and then just throw it up onto any old web server that’s not equipped for it. A website needs a literal solid foundation. A home to live and work that is as specific to it’s needs as possible. Yet so many web developers just throw the site up on a host and consider the project done.

The big problem is the fallacy that “all you need is PHP” a lot of clients (and devs) have in their mind. It’s not really the client’s fault though; how could they understand the nuance of using a tool like ExpressionEngine, that’s built with a PHP framework like CodeIgniter? Nope, the problem lies with us, the web developers. A lot of us just don’t know what the hell’s going on with the server.

It’s the FRAMEWORK Keeping You Down

PHP, by itself, is pretty lightweight. If you want to display a simple PHP script that connects to a database, compiles information about something, and then display the HTML, using native inline procedural PHP is pretty efficient. It’s also time consuming, likely to be insecure, tough to maintain while keeping ones joy and sanity, and just an all around pain in the ass. So, smart developers use frameworks like CodeIgniter (the framework used for ExpressionEngine).

As a programmer, frameworks are great. They’re pretty much the antithesis of the above. As ExpressionEngine is to building a website, frameworks are to building tools like ExpressionEngine. Most frameworks take security seriously, are easy(ish) to maintain, and are a pleasure to work with (or at least make an attempt to not be an absolute pain). But it usually comes at a cost; performance. It’s a given rule that any time you use a framework you’re going to need more server resources made available to your program.

The biggest reason for this is because frameworks just have a lot of PHP files that do a lot of complicated stuff behind the scenes. Pretty much everything is abstracted and object oriented and polymorphic and buzzword, buzzword, buzzword. It’s a lot of processing. And when you take into account that PHP is an interpreted language that has to compile the PHP on every request it starts to add up.

Introducing the PHP Opcode Cache

To get around dealing with the large number of PHP scripts a framework all but requires a PHP Opcode Cache (or PHP Accelerator). An Opcode Cache is a PHP module that takes your PHP scripts and caches the compiled bytecode so later requests don’t have that overhead. For those that don’t what that means, suffice it to say that using a PHP Opcode Cache will improve your PHP performance by, in my experience, anywhere from 60 to 90%. This is serious improvement I’m talking about. More than that, it’s also the most cost effective in terms of time investment and overall implementation pain.

For example, the process of getting setup is ridiculously simple using the Alternative PHP Cache (APC). On my new Ubuntu VM, it was literally 1 command:

aptitude install php-apc

That’s it. I run that single command on my server and all my ExpressionEngine sites are running at an average of 4MB on the homepages and at a tenth of a second request time using APC (down from 25MB and 1.5 seconds).

In terms of PHP Opcode Caches, I have 3 personal favorites (though there are lots of others): APC (obviously), eAccelerator, and XCache.

APC

APC is the one I’m currently using for my server. Not because it’s the best Opcode Cache out there but because, as the above demonstrates, it’s crazy simple to get up and running (I’m lazy) and my current needs don’t require more than the “good enough” it offers.

The really nice thing about APC (outside of crazy simple setup) is the maturity. It used to be implemented by Facebook (who also contributed to the project) and has been endorsed by the the people behind Zend. In fact, APC is supposed to be integrated into the core of PHP no later than 6.0 (though I think they’ve moved this to 5.5 though I could be wrong).

eAccelerator

eAccelerator has been around for about 9 years now and is my go to when shaving a couple extra MBs of memory matters. The performance return on eAccelerator is really impressive and in my experience it gets no better. eAccelerator is also the Opcode Cache use by cPanel and WHM managed servers (by default) which I think says a lot.

The big downside to eAccelerator is that it’s sort of a pain in the ass to get setup on the command line though. It requires building things custom to the platform and it also needs to be rebuilt every time you update PHP. Definitely an advanced option.

XCache

XCache is a really nice Opcode Cache in my experience. For Windows hosting it’s an absolute must and I’ve used it in production on quite a few projects. Setup is simple and straightforward and I have yet to experience any issues on installation. The performance gains are similar to APC though it does depend on what you’re doing and how it’s being done (both work differently so some things work better on one and not the other).

I have had issues with it though. I’m not entirely sure what the root cause of the issue was/is but with Zend Framework based sites XCache didn’t work out quite so well. It’s been a couple years since I’ve used it so this may be a non issue.

Additional Considerations

There are lots of other techniques you can use to improve the performance of your PHP site outside of an Opcode Cache but none can give you the return quite like it. Adding things like MySQL query caching, or memcached, or a number of other things can help improve things further but you’ll never get the return like on an Opcode Cache.

One thing to keep in mind is that an Opcode Cache can also become a crutch. It’s crucial that one not be used during development. If what you’re building needs an Opcode Cache in order to function you’ve likely made some serious errors elsewhere. Using an Opcode Cache during development will hide this from you and possibly hurt things later.

For production though, an Opcode Cache is an absolute requirement. If you have a dedicated server you’re sort of on your own in terms of implementation. Google is your friend. Things like “Ubuntu install eAccelerator” will do you good (or whatever OS you’re using). For managed hosting though, just send an email to your host and ask them to install the Opcode Cache you want. You’ll be seriously amazed at the speeds and footprint of your sites.

Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.