Short discussion about APC user cache vs Redis vs Memcached vs... whatever clone

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
PlayfulWolf's picture

Hi,

Why there are so many installations and topics about memcache/redis and clones for Drupal instead of using APC user cache (not opcode)
I see the benefits in those scenarios:
1. Multi-server instalations
2. PHP configurations, where multiple threads/processes cannot share common APC user cache

What I haven't experienced:
1. Memecache is faster that APC - wrong! It is slower. Do simple tests and see, that it is 10-30% slower
2. More stable - wrong! I had some headaches in the past with memcache services, but none with APC fragmentation, just heard it on forums. Lets say it is because stable/old centos platforms I prefer to use, often with mod_php of Apache.
3. More features from memcache - right... but most likelly you will not need them at all
4. Ability to use memcache on multi server installations - the truth is that 90% of the sites will never get out of single server stage and if they wil - you most likelly to change server/isp/drupal core version until site grows, so why yet another semi-redundant service?

So, why are your thoughts? Maybe I am missing something - I do not work full time as system administrator... ;)

Comments

The APC cache isn't shared

Mark Theunissen's picture

The APC cache isn't shared between machines, so if you have multiple web heads they all have their own copy of the cache items, which is wasteful and can be problematic depending on which cache we're talking about (e.g. cache_form).

Also, I disagree on point 2. APC is unstable. It works ok when you throw tons of memory at it and just use it for opcodes, but try anything else and I bet you'll hit many issues. There are plenty of issues just trying to run it for it's main purpose.

However, I wouldn't recommend going for memcache either, unless you have a high number of registered users. It also causes endless headaches - the Drupal memcache implementation of session handling was so broken, and it adds an extreme level of complexity to a large site. It may or may not be fixed at the moment.

I didn't like how the opcode

brianmercer's picture

I didn't like how the opcode cache would become fragmented if I used apc as data cache.

Also, drush can't clear the

brianmercer's picture

Also, drush can't clear the apc cache, which can be inconvenient at times when you're used to just doing "drush cc all".

Personal Memcached/Memcache Headaches

ryan.merritt's picture

Speaking from some painful and less than adequate experience (yes, I didn't really know what I was doing nor had the time to spend to learn it perfectly) with memcache, I had a very hard time with memcached/memcache and its even more numerous modules that cater to each of the two variants separated by a d at the end (wasn't a d at the end of a process name reserved for the daemons ?).

After using APC and being very happy, my 99.99% non-anon user drupal site was dragging slowly thanks to views and cck shared-fields (or, single table fields) performing JOINs for what seemd like days. I began reading about memcached on numerous sites, including pressflow's wiki, and having heard of memcached before I figured it was time to go all in.

2+ new modules for drupal including an edit to settings.php, a new daemon on localhost and a php5 pecl installation I thought I had made a good go of things. As i shut off the daemon, turned it back on, shut off the drupal module, turned it back on and tweaked it I had been receiving little to no feedback on if memcached was working or not for the site aside from the memcachestat module.

Performance was slightly gained (at first) despite the additional layer of complexity and confusion with yet another caching solution introduced to the stack.

I had session errors and issues that made little to no sense, cross talk among drupal sites that didn't share databases, failure of modules randomly and eventually a breakdown in the uploading of files for specific content types. I then tried to just disable memcached module on the site and got random errors from a long-since-not-used me aliases module and could not successfully detach memcache from the site at this point.

In rebuttal, I spun up a new VPS, migrated the drupal site as is with a tunnel to the exact same database, and eliminating just the files from memcache/d and the settings.php entry with a cache flush and every problem disappeared.

I am not intending to flame or bash memcache, it clearly works very well and in hindsight it is also much more complex than I can handle or had the time to be thorough with as i set it up with apache and the drupal install. It is highly talked of and this I do not argue.

But in my instance, involving inescapable queries to the database for nearly every pageview generated by exclusively logged in users, the performance gains vs the ambiguous and hard to debug errors that could be coming from the drupal module, config files, or even something more obscure was just barely less than a nightmare.

Post migration performance after the slow-motion degradation of my poorly assembled memcache drupal install has skyrocketed and problems I didn't even think to attribute to memcached are gone.

With that said, does anyone have any good writings on pitfalls of memcache/d ? ;)

Edit: Turns out this is due to not using different memcache keys for the different sites and can not be done by having different tables or prefixes alone on the sites using memcache.

Sounds like the problems that

dalin's picture

Sounds like the problems that you describe are primarily from not adequately reading the documentation. I think you would've experienced the same issues had you tried to use APC for object storage.

We've been using Memcache with hardly a hitch for years. Yes the integration with Drupal sessions has caused issues for some people, that's why there's big bold warnings about it. I've only ever had issues with the Drupal lock integration which also has big bold warnings on it.

Perhaps about 75% of sites that we launch are on more than one web-head which automatically eliminates APC as an option. In addition to the problems that other people listed, cache clearing is probably the most significant reason why APC can't work with multiple web-heads: if you clear the cache you are only clearing it on one web-head, the other web-heads will being seeing stale data. Depending on what the data is it may trickle down and cause numerous hard-to-debug errors. Additionally APC only has a beta release for D7. Therefore we've standardized on Memcache even on sites that only run on one web-head. From our point of view maintainability is more important than the 10-30% increase in performance of the cache system on just those few sites that run on a single web-head.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

APC + memcache on multiple web-heads

doublejosh's picture

This seems acceptable though yes?...

Use APC opcode cache on multiple Apache/PHP web-heads. Then place memCache on either the DB server or a dedicated server.