LinuxJedi's /dev/null

As some of you know I use Ubuntu Hardy (alpha) on my MacBook Pro.  Some think I am insane and twisted (and perhaps I am) but I find it much easier to do my day-to-day work on than Mac OSX.

Anyway, the one thing I found very strange about Ubuntu Hardy is that it favors XCache for an opcode cache without packages for eAccelerator or APC.  I personally use APC on all my servers for several reasons:

1. eAccelerator was segfaulting on our production servers after about a week of usage
2. At the time of evaluation XCache was still in its infancy (I'm sure its pretty good)
3. APC is a lot better than it used to be
4. APC is said to be included in PHP6

Anyway, if you want something done, do it yourself, and using that philosphy I have built a DEB for Ubuntu Hardy for APC which can be found in my downloads section.  It is currently for a 64bit install only but can be rebuilt for i386 and it should even rebuild on Gutsy.  I will try to keep the binary up to date as new versions of PHP are released on Hardy.

In my previous post on the subject I stated that Memcache was faster at storing arrays than APC was by quite a large margin.

I will re-itterate that the 2 aren't really comparable in their target design. Memcached is designed as a distributed cache and as such is expected to be slower than APC. That said Memcached is still bloody fast and in my opinion one of the top server enhancement tools of the decade (as is APC, but I praise it more for its op-code caching abilities).

'Fail' responded to this and stated that I should serialize the array first (sorry, comments were not ported when I changed blog software), which I have since tried.  It brings the APC store time down to a respectable 2 seconds from 13 seconds on the same testing environment.  I guess my question now is: why doesn't APC serialize automatically when it detects an array?

Anyway it has helped massively with the caching methods I use now.  I now go by the rule that small commonly accessed items (such as main menus) are stored in APC and larger items (such as articles) are stored in Memcache between multiple servers. I don't really worry if the data is a string, array or object.

I do intend to follow this up with a graph comparing APC, Memcached, file based cache and MySQL's query cache but that will take some time to prepare, mainly down to the fact that my laptop now has Ubuntu Hardy in it which has no APC build.

I have been benchmarking APC and memcached to find which is the best in certain situations. Obviously APC is a much faster cache but memcached is designed for scaling across servers.

The most interesting thing I found is APC is a lot slower at storing arrays than memcached. In most cases it is still faster at reading them. For example on my test virtual server, with 4k of text memcached will do 100,000 writes in around 4 seconds whereas APC will do 100,000 writes in around 2 seconds. If I instead try to store a small array with 8 elements memcached constantly does 100,000 writes in 4 seconds, APC however takes 13 seconds! This figure seems to grow exponentially as the array grows as well. Reads speed appears to be consistent for each with around 4 seconds for 100,000 memcached reads and 0.5 seconds for 100,000 APC reads.

In the application I was working on we are storing some large arrays and some small segments of data. The smaller segments of text data also changes a lot less often than the arrays so we are storing the small text data in APC and the arrays in memcached.

Note: I am not using current versions of either APC or Memcached for this, I know both have had a couple of new releases and both have had speed improvements.

I have been asked several times about why I choose APC over any other PHP opcode cache for our site. There are several around nowadays, the big open source ones being eAccelerator, APC and XCache. I am a big advocate of open source and I'm much more likely to get upper management to agree to free software than an expensive alternative from Zend. As far as speed difference goes there isn't a great deal of difference between them, I could make code optimisations that would give us a better performance increase.

First I had to admit it was not my first choice, we were using eAccelerator to start with, but we were then developing problems that were killing Apache processes. After a bit of research I found this was a known problem with no real fix (it may be fixed now, to be honest I haven't looked back). It was decided that we needed to evaluate the alternatives to eAccelerator as soon as possible.

I had a brief look at XCache and have no doubt it is a great project, but at the time it was still in its infancy. This would have been the last solution evaluated simply because we prefer software that is well established.

APC is well established and since it was announced that this would be included in PHP6 it has been stabilised very well. We tested it to death and it responded well, within a few days it was across our whole hosting platform.