Epiphany - a salute to APC

[Michael A. Peters]

I'd never bothered to use an opcode cache before.
Sure, I had used accelerators that cached includes and stuff in ram, but
damn - APC has made my site (at least on dev machine) snappy.

It wasn't too bad before, but I make heavy use of the database.

This is necessary for me to make maintenance easier.

IE - my site deals with biology and latin names, and now that various
mtDNA tests are cheaper, there's a lot of taxonomy change going on.

First my beloved Hyla regilla changed to Pseudacris regilla, now (though
I disagree) it may be split with my species becoming Pseudacris sierra.

American Bullfrogs, Western Toads, several species are likely to have
changes to their taxonomy soon that I do agree with. So I have a unique
ID and every page where a species is mentioned, common/latin names are
grabbed from the DB so I can do a single SQL update and the entire site
is modern (and easily reverted too).

Anyway - I have a crap load of tables and a lot of queries per page, but
the results most queries almost never change. Caching the results with
APC has made things a lot faster.

But I even went beyond that. My site is all created via DOMDocument.
Most of the pages have a content div that rarely changes. Even though
caching the database sped it up, I found that on complex pages that used
a lot of calls to DOMDocument functions but rarely actually change,
creating the main content div as a separate dom object, exporting it to
an XML string and caching the XML string, and then importing the XML on
subsequent page loads sped them up as well.

I'm not done with the mods yet - there's a few places where poor code
design on my part makes it more difficult to do the separation of
content that can be cached, and I need to go to all of the sql
insert/update statements so the appropriate cached key/value pairs get
deleted upon successful insert, but damn - it makes a HUGE difference -
and I'm only doing opcode caching (APC breaks pear::MDB2). Once I figure
out how to tell it to cache includes EXCEPT for /usr/share/pear - I may
even squeak out more performance.

It's the 4th of July so lists are slow, so I just wanted to take my hat
off to the APC team. It absolutely rocks.

For others like me who just never bothered to look into it, look into it.

Only caveat - don't use it on shared hosting (maybe safe with php-cgi in
shared hosting), and don't call apc directly - call functions that wrap
apc so you can gracefully disable it (or even change to a different
opcode cache) - IE

function wrap_delete($key) {
    $key = 'sherp_' . $key;
    if (function_exists('apc_delete')) {
       $value = apc_delete($key);
       return $value;
       } else {
       return false;
       }
    }

function wrap_store($key,$value,$life=3600) {
    $key = 'sherp_' . $key;
    if (function_exists('apc_store')) {
       $rs = apc_store($key,$value,$life);
       return $rs;
       } else {
       return false;
       }
    }

(the sherp_ in above wrappers is just so that I don't have to worry
about collisions with other web apps I run that I port to apc. Kind of
like namespacing)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Brandon Johnson-2]

you think this is similar to http://www.danga.com/memcached/ or you think
this method would be faster ? Which do you say would be the greatest
benfit ?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Eddie Drapkin]

if you want a pure opcode cache, APC is a great choice.

APC should //not// be used for persistent RAM storage.  Memcached is
much faster and designed for that aim, while not being tied to the
webserver.

On Sun, Jul 5, 2009 at 2:10 AM, Brandon Johnson<brandonleej@...> wrote:
> you think this is similar to http://www.danga.com/memcached/ or you think
> this method would be faster ? Which do you say would be the greatest
> benfit ?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[pscott]

Eddie Drapkin wrote:
> if you want a pure opcode cache, APC is a great choice.
>
>> you think this is similar to http://www.danga.com/memcached/ or you think
>> this method would be faster ? Which do you say would be the greatest
>> benfit ?
>>
A simple rule of thumb that I use is:

If you have one machine and medium to large traffic loads, go APC
If you have more machines for caching servers (dedicated) and large to
holy mofo loads, then go MemcacheD

This ALL assumes that you have followed a logical scalability plan and
have separate DB servers, app servers and possibly even using a CDN or
something beforehand.

-- Paul

http://www.paulscott.za.net/
http://twitter.com/paulscott56
http://avoir.uwc.ac.za

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Brandon Johnson-2]

ok thanks for information was just something I was reading about the
other night. Then I came across this message.

Brandon

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Eddie Drapkin]

On Sun, Jul 5, 2009 at 2:43 AM, Paul Scott<pscott@...> wrote:

> Eddie Drapkin wrote:
>> if you want a pure opcode cache, APC is a great choice.
>>
>>> you think this is similar to http://www.danga.com/memcached/ or you think
>>> this method would be faster ? Which do you say would be the greatest
>>> benfit ?
>>>
> A simple rule of thumb that I use is:
>
> If you have one machine and medium to large traffic loads, go APC
> If you have more machines for caching servers (dedicated) and large to
> holy mofo loads, then go MemcacheD
>
> This ALL assumes that you have followed a logical scalability plan and
> have separate DB servers, app servers and possibly even using a CDN or
> something beforehand.
>
> -- Paul
>
> http://www.paulscott.za.net/
> http://twitter.com/paulscott56
> http://avoir.uwc.ac.za
>

There are several problems with using APC instead of memcached, even
on a single machine:
1) APC is tied to the wbserver.  This brings up a lot of (not so)
obvious problems.  The processing is handled by the webserver, instead
of a dedicated process.  This can mean that a CPU intensive APC
operation ties up the webserver, which results in less concurrency for
your site, while just waiting to hear back from memcached means idle
webserver process, which allows for greater concurrency.

2) APC is designed to be an opcode, first and foremost.  And while it
may perform as well, or better, on infrequently modified data,
memcached is designed and optimized internally to map memory chunks
and utilize best memory management practices, which mean data that
changes frequently is better stored in memcached.  There's a slideshow
somewhere about facebook's internal caching, and they store things
like school names / info in APC, because fetching it is a tad faster
(especially localhost v. network), but the constant rewiring of
webserver memory is a bad idea, so they store data that changes often
(like status updates) in memcached.

3) memcached has a much richer, better API.  Things like CAS can solve
race conditions, while APC cannot.  There's also increment/decrement,
replace, etc. etc.

4) APC shares its memory between storage and opcodes, afaik.  So, you
fill up APC too much and you start to lose your cached opcodes?  I'd
rather not.

5) APC, once again, is tied to the webserver, so a webserver restart
means you either have to a) prime your cache or b) let your database
be hammered while you "live prime" the cache.  Neither of these are
particularly pleasant, as cache priming is a very difficult task,
while allowing direct read access to the database on all pageloads is
usually a problem when you have to have a key-val cache system in
place.

Long story short, if you're using some sort of RAM based cache to
store heavy data, use memcached, while light data (configuration
values read from a text file, maybe) are fine in APC.

--Eddie

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Michael A. Peters]

Brandon Johnson wrote:
> you think this is similar to http://www.danga.com/memcached/ or you think
> this method would be faster ? Which do you say would be the greatest
> benfit ?
>

In my case I think apc is better because I'm single server xen host and
(after reading the other posts in thread) most of my data rarely
changes. New data is added but existing data doesn't change often.

-=- (from other discussion)
Interesting that facebook uses both. The fedora maintainer for the apc
rpm listed it as conflicting with memcache. If you can use both, that's
a fedora packaging but that should be fixed.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Eddie Drapkin]

> -=- (from other discussion)
> Interesting that facebook uses both. The fedora maintainer for the apc rpm
> listed it as conflicting with memcache. If you can use both, that's a fedora
> packaging but that should be fixed.

I've never seen, nor heard of, a full scale caching implementation
that doesn't use both.  Digg uses both, too.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php