XCache or APC?


Well-known member
Some recommend XCache over APC for performance, personally for me I use APC as it is now part of PHP and maintained by the same folks. In all honestly I have not noticed a difference (and I used to use XCache all the time).


Formerly Dinh Thanh
In this article, the author concluded that xCache is faster and more stable.
I agree with him, xCache is faster and less bugs.

In the second run though both xcache and apc have the same transaction rate of 1.53 which is 23% higher than that of no cache 1.24, but the longest transaction and shortest transaction of xcache was better than that of apc. It shows that xcache handles caching better than apc.
Eventually, there were some bugs in apc caused crashes when i tried to implement it. And xcache ran fine without any issues. This scenario shows that xcache is better.


Well-known member
In my setup eAccelerator ended up being about 10% faster than APC/XCache. But even so, I uninstalled eAccelerator when they decided to remove a bunch of features I used in their newest version.

Previous eAccelerator versions also provided functions for use in PHP scripts that allow access to shared memory, automatic web (content) caching, and other related tasks. These were removed as of version 0.9.6rc1.
Seems like it was a good choice to remove it these days... development has more or less stopped.

I think the thing that made eAccelerator a little faster was because it had not only an opcode cacher, but also a code optimizer.

Currently I use XCache (I used APC before I switched to eAccelerator). I've been tossing around the notion of going back to APC since it's a "little more official" (if there is such a thing) with PHP devs working on it. But it's also one of those things where if it's not broken, don't fix it. :)


Well-known member
I use X-Cache. Used it before on my vB. It's fast and I have no Problems till now.
I use it for my XF and two WP.


Well-known member
I'm using xCache as well and haven't had any problems. However, xCache was made by the developers of lighttpd, benchmarks show it performs similiarly to eAccelerator and faster than APC. Either way APC is handled by the same developers who work on PHP, so that might have something to say for it.


Active member
In practice, you won't see a difference. However, since APC is now bundled with PHP 5.4, if/when you upgrade to that, you won't need to worry about ever again installing a separate opcode cacher.

As far as caching objects goes, I'd go with memcached as it offers a great PHP API.


Well-known member
In practice, you won't see a difference. However, since APC is now bundled with PHP 5.4, if/when you upgrade to that, you won't need to worry about ever again installing a separate opcode cacher.
It is??? I knew they were planning it for 6.0 at least as an optional compile option, but didn't know it made it into 5.4.


Active member
APC is not going to be in 5.4. Not sure where you got that from.
You are right. It looks like Wikipedia lied:

Alternative PHP Cache is a free, open source (PHP license) framework that optimizes PHP intermediate code and caches data and compiled code from the PHP bytecode compiler in shared memory. APC is quickly becoming the de-facto standard PHP caching mechanism as it will be included built-in to the core of PHP starting with PHP 5.4. [1]
5.4 B1 did not bundle APC so it looks like we'll have to wait for it...guess they prioritized other things (look at all the syntax changes!). Maybe they thought APC isn't stable enough yet? I installed it on my server and if I don't allocate more memory than all my scripts combined use, apache starts segfaulting (w/ APC 3.1, 3.0.19 was fine but it doesn't support PHP 5.3.8).


Well-known member
I used to use apc but I saw many segfaults in our logs when it was enabled. Now I have installed xcache and everything seems fine. Xcache seems more stable to me.
Hi all,

Which php handler did you use with Xcache?

It seems compatible only with Dso or Fcgi. Which is better between them?

My Hosting say also that with Dso, could have some risk for security.