Hi,

I'm after some support/tips really. I have used the old memcache module for Drupal 5.x in the past very effectively. In fact, the application I was working on at the time showed about a 1000% performance increase with memcache being used instead of Drupal normal caching (tests done with JMeter), before any query optimisation, when touching a standard user profile page and the home page of the website in a pattern taken from our server logs. And that was just on our local machines. It was even better on the dev servers (separate web and db servers).

So, I installed Cache Router for Drupal 6.x, downloaded the Windows port of memcached, configured everything and did some tests. For some reason the application here was 30% *slower* with memcache working. Hmmmm... perhaps Windows? So I did the same checks on our RHEL 5 dev server but got the same outcome - the overall times were quicker, but memcache was still 30% down on "normal" Drupal db caching.

This flies in the face of my past experience with memcache, so I'm thinking we must be doing something stupid. Can anyone offer any suggestions, ways of monitoring what is actually coming and going from memcached (maybe it's not actually working at all and failing silently?) etc...

Any help greatly appreciated!! =)

CommentFileSizeAuthor
#1 Andras - Memcache On.png28.08 KBgreg.harvey
#1 Andras - No Cache.png27.58 KBgreg.harvey
#2 Andras - DB Cache On.png27.93 KBgreg.harvey
#2 Andras - Filecache On.png28.08 KBgreg.harvey

Comments

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented
Title: Cache Router seems to be failing to communicate with memcached » Strange bench test results show memcache is slower than Drupal db caching
Category: bug » support
StatusFileSize
new Andras - No Cache.png27.58 KB
new Andras - Memcache On.png28.08 KB

More info - please see JMeter results on a clean(ish) Drupal 6 installation, attached. Note that with memcache *on* and Performance settings set to "normal" caching the site runs at half the speed it does with caching disabled!

Settings look like this:

$conf['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$conf['cacherouter'] = array(
  'default' => array(
    'engine' => 'memcache',
    'server' => array('localhost:11211'),
    'shared' => TRUE,
    'prefix' => '',
    'static' => FALSE,
    'fast_cache' => TRUE,
  ),
);
greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented
Title: Strange bench test results show memcache is slower than Drupal db caching » Cache Router seems to be failing to communicate with memcached
Category: support » bug
StatusFileSize
new Andras - Filecache On.png28.08 KB
new Andras - DB Cache On.png27.93 KB

Actually, I'm going to move this to a bug report, since it seems fairly clear memcache is not working. Results indicate memcache is not doing anything, despite being installed and operational. This has been tested across three machines, Windows XP, Fedora 10 and RHEL 5, just to rule out system issues. And to demonstrate, with File caching on performance is markedly increased compared to straight db caching (see attached) so it seems it is just memcache with a problem.

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented
Title: Strange bench test results show memcache is slower than Drupal db caching » Cache Router seems to be failing to communicate with memcached
Category: support » bug

Also tested XCache, which ended in the white screen of death - investigating that one now. =(

File cache works great though! =)

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented
Status: Active » Fixed

Problem was not with Cache Router - it was memcached seemingly not playing nicely with PHP 5.2.6 on RHEL 5 (though also not on my Windows machine, which I haven't experienced before!)

Installed the RPM for memcached here:
http://www.pramberger.at/peter/services/repository/rpm2html/rhel5/i386/m...

This updates to the latest for RHEL 5 and works great! =)

slantview’s picture

slantview commented

i love when these problems fix themselves. hope everything continues to work well, and hopefully we can get xcache working well soon !

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

LOL! Thanks. RHEL certainly causes issues with the latest version of anything, it seems. Their repositories are always about a year behind, because of their rigorous testing and acceptance procedures, so running forward-focussed development projects like Drupal on RHEL is always going to cause a little pain.

Nothing insurmountable though.

For our part, we won't be investigating XCache further, as we won't be using any opcode caching solution due to documented Apache instability under high load with all the opcode options. Still a bit weirded out by memcache Windows port not working with PHP, but I guess it hasn't been updated for some time either, and I downloaded the latest version of XAMPP about 2 months ago, so I guess it suffers the same issues as the memcached that ships with RHEL and doesn't play nicely with PHP 5.2.6+. Worth knowing! =)

slantview’s picture

slantview commented

To be honest, I've used APC on quite high load sites (Lifetime Television, Fast Company, DivX) and it seems quite stable at this point. Two years ago I would have agreed with you, but the latest versions are very stable. I can't speak for XCache however which seems to have slowed down on development and has a number of issues.

At this point, I can't imagine running a Drupal site without it, even if you're not using it for it's user memory caching.

Oh, and when I say "quite high load sites" we are talking from about anywhere from 20m - 50m pageviews per month.

Best,

Steve

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

Cool - thanks for the feedback. To be honest, it won't be my decision anyway and I think the sysadmins are nervous after reading negative feedback on the matter. Which is understandable. And memcached being distributable is very handy too! =)

andypost’s picture

andypost
he/him
Primary language Russian
commented

@slantview What version of APC yu are using? For my sites I prefer eAccelerator which I find is quicker and more stable than APC.

Another argument for me - eAcc eats less memory then APC (why I don't know)

Half of year ago I investigate Apc-eacc-xcache under centos 4 (apache 2 + mod_php 5.2.6) and eAcc was winner...

slantview’s picture

slantview commented

@andypost -

Version of APC is typically 3.0.x where x is whatever the latest is. And tbh, a year ago, APC was less stable than eAcc. But we had a ton of crashes with eAcc and so we switched to APC and it has been rock solid.

eAcc is faster, but with high load it crashes, a lot.

Make sure you use a prefork server and not a worker cause typically even when the opcode caches say they are "thread safe" they are not. Even PHP itself doesn't claim to be 100% thread safe.

Ref: http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

Why shouldn't I use Apache2 with a threaded MPM in a production environment?
PHP is glue. It is the glue used to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. When you make the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, feet of clay are introduced into PHP's system.

If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space.

And finally, this warning against using a threaded MPM is not as strong for Windows systems because most libraries on that platform tend to be threadsafe.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.