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 :)


On Mon, Jun 1, 2009 at 9:44 PM, Daevid Vincent <dae...@daevid.com> 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:oorza...@gmail.com]
> > 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).

Reply via email to