EAcellerator is "just" an opcode cache. It transparently caches PHP opcodes; all you have to do to use it is download, compile and enable and never worry about it again. APC, on the other hand, does a bit more. While APC also caches opcodes, it performs worse than EAC or xcache does (there's a bit of debate as to which is better, for my particular needs, EAC was marginally faster, but both outperformed APC) for opcode caching. APC, on the other hand, also has some useful features that aren't related to opcode caching, but rather apc_store, apc_fetch and apc_define_constants. If you install apc and don't set apc_enable=1 in php.ini and leave the opcode caching to EAC / XCache, you still have the ability to use those three functions, which allow you to have persistent values in RAM between requests, which is really useful if you have a lot of generic data that never changes but is needed often. I personally use apc to set and fetch global variables and constants and allow EAC to cache the opcodes. It gets really hairy if you decide to use memcached in conjunction with an external opcode cacher and APC, because there's specific cases where APC is useful to store/fetch persistent data and other cases where memcached makes more sense to use. I recommend reading www.scribd.com/doc/4069180/Caching-Performance-*Lessons-from-Facebook * for a good analysis of when and where and how to implement the two in tandem. Speaking more generically, building with memcached in mind is a huge paradigm shift from your typical php/mysql architecture, as you have to compensate for the fact that the database is dynamically changing, and either abstract away, or manually manage the data structures in memcached. There's two strategies - hard mode and extreme mode, if you will - to doing this: delete every key when the data within them changes, or dynamically update them as the database changes (theoretically offering you the potential to have 95%+ cache hit rate, with database reads being a rare case). It's a lot more difficult to drop in later than it is to design with it in mind, and in many cases implementing it means re-writing a lot of legacy code, but the fact of the matter is that a solid memcached implementation can all but bypass the SQL database altogether (and by doing so bypass the bottleneck for the vast majority of requests) and there's nothing else that offers the performance increase of memcace (orders of magnitude). If you'd like a more complete example - with (pseudo)code example, let me know and I'll write out something more descriptive. If you're worried about scalability, there's a few links I'd recommend: http://highscalability.com/ - blog dedicated to scalability, has talks with a lot of huge, high visibility sites (not all built on php) including, but not limited to, digg, facebook and wolfram|alpha www.*mysqlperformanceblog*.com/ - another blog dedicated to performance, but less generically and more how to squeeze the most out of mysql. It's run by Percona, which is a very respectable company despite their flaws, and they also distribute XtraDB, the easiest way to increase MySQL performance. Pardon me for assuming you use MySQL if you don't. http://blog.facebook.com/ - facebook's official blog, often has useful talks and links about the ways they've solved their scalability problems. http://blog.digg.com/ - same as previous, save for digg You'll have to dig (pun not intended) through a lot of cruft for "the good stuff" with those last two links, but you can easily spend several hours on the first two links and all four offer pretty impressive advice. Let me know if there's anything else I can do for you :) --Eddie On Mon, Jun 1, 2009 at 9:44 PM, Daevid Vincent <daevid@xxxxxxxxxx> wrote: > Eddie can you explain the differences between APC (which is now built into > PHP) and EAccelerator. You seem to give mixed signals here as you endorse > both it seems, but I would think they would collide and as the Highlander > says, "There can be only one!" > > http://us.php.net/apc > http://eaccelerator.net/ > > Why would we choose one over the other, or do they really work in tandem > together? > > We looked into memcached or memcache or some $hit (it's too confusing and I > don't remember the exact one) but after installing, we realized it would > not > work so well for us as it makes your SQL queries potentially stale. In our > case, they all have to be live and accurate. And there is a 1MB data limit > per cache object. :( > > http://us.php.net/manual/en/book.memcache.php > http://us.php.net/manual/en/book.memcached.php > http://www.danga.com/memcached/ > > However we did install the APC and that seems to work very well for caching > the page's opcodes, and are quite pleased with it so far. Plus it's nice > that it's an "official" module for PHP and a simple apt-get install. > > > -----Original Message----- > > From: Eddie Drapkin [mailto:oorza2k5@xxxxxxxxx] > > Sent: Tuesday, May 26, 2009 8:20 PM > > > > 2) It's easier to start with a persistent caching > > setup and go from there than apply one later. Look into memcache, > > memcachedb, and __apc__ for some absolutely required tools. > > > > 6) Install an opcode cache, I recommend __EAccelerator__. Script > > CPU time will be decreased by (a) order of magnitude(s). > >
