Version 13 (modified by AlexisWilke, 6 years ago) (diff)

Well... The first paragraph was neat, but the others needed a little help. 8-) Better English.

Introduction to XCache

XCache is a open-source opcode cacher, which means that it accelerates the performance of PHP on servers. It optimizes performance by removing the compilation time of PHP scripts by caching the compiled state of PHP scripts into the shm (RAM) and uses the compiled version straight from the RAM. This will increase the rate of page generation time by up to 5 times as it also optimizes many other aspects of php scripts and reduces serverload.

The XCache project is lead by mOo who is also a developer of Lighttpd. Lighttpd is one of the fastest webserver programs and outperforms Apache and many other open source webserving projects so the same is being done to XCache.

Do you (the author of XCache) know apc, eaccelerator, phpa, truck-mmcache ?

Yeah, i know them very well.

I noticed phpa (PHP Accelerator) long ago, and looked at truck-mmcache around the time it was still being actively maintained. Sadly the phpa project died and never updated its code to support new releases of PHP. So I used truck-mmcache for a period of time, but... it hanged or crashed continuously when used under high load. I noticed APC later and I've been reading the source code for a long time (I couldn't have written XCache if I hadn't read those sources), discovering that APC code is simpler and more beautiful than mmcache's. Features are good, but I believe that stability is more important. So I finally turned to run APC online -- simpler often means more stable. mmcache forked eaccelerator later and they setup, running trac.

But why do you write XCache after that? Why not contribute to ea/apc?

I DID file bug reports, submit patches to both[=APC&status=All apc bug report system] and truck-mmcache on and interact with zoeloelip, one of the main developer of eaccelerator. He's the first one who read my XCache source, long before XCache was published online. I'm not sure, but I think that his idea of rewriting ea_dasm.c is based on my Disassembler idea in XCache :)

There are many reasons for me to write XCache instead of using APC or EA:

  • Some things are too big to be implemented in those other projects (ea/apc).
  • I have many new ideas on opcode cacher, but I just can't break their cacher to prove that my ideas would improve performance.
  • To prove my programming skills? Running your own project isn't that simple. Just programming skills are not sufficient, you need to become a project admin, design how the project will move forward, foresee the costs and benefits ... blah blah

To conclude, I've finished writing XCache for quite a long time, before then I used APC. Although it was quite stable for a php4 with flock() configuration it had become unstable once I upgraded my server to a dual cpu (4 threaded cpu) because it flock()ed badly so I used XCache instead and it seemed to solve the problem.

ea/apc are still good opcode cachers, as long as they get maintained actively, and if they are stable for you.

What's special in XCache?

see FeatureList.

By the way, I focus my effort to keep XCache stable.