It seems that using pecl-memcache in binary mode with this module breaks my site. I start finding database query errors and broken pages immediately. My configuration is below.

By removing the $conf['lock_inc'] from settings.php allows the site to come back. IE, no broken front page although sessions won't work or allow a login.

Removing $conf['session_inc'] allows logins and the site proceeeds to operate. However, checking the stats on the memcache servers shows zero cmd_get or cmd_set or caching at all. Everything stays at 0 although I can see connections being made.

Based on the above, would it be fair to assume that binary mode with pecl-memcache has not yet been tested or implemented?

My details:
memcached-1.4.7
pecl-memcache 3.0.6
drupal memcache module 6.x-1.x-dev, 09/26 (current -dev as of this post)

memcache.ini options:

extension=memcache.so
memcache.protocol=binary (this breaks, so I flip back to ascii)

Settings.php options:

$conf['memcache_extension'] = 'memcache';
$conf['memcache_persistent'] = TRUE;
$conf['cache_inc'] = '/path/sites/all/modules/memcache/memcache.inc';
$conf['session_inc'] = '/path/sites/all/modules/memcache/memcache-sesson.inc';
<b>$conf['lock_inc'] = '/path/sites/all/modules/memcache/memcache-lock.inc';</b>
$conf['memcache_servers'] = array(
         '127.0.0.1:11211' => 'default',
         '127.0.0.1:11212' => 'menufilter',
         '127.0.0.1:11213' => 'path',
         '127.0.0.1:11214' => 'form',
         '127.0.0.1:11215' => 'block',
         '127.0.0.1:11217' => 'views',
         '127.0.0.1:11218' => 'content',
         '127.0.0.1:11219' => 'apachesolr',
         '127.0.0.1:11220' => 'sessions',
);
$conf['memcache_bins'] = array(
          'cache'               => 'default',
          'cache_rules'         => 'default',
          'cache_admin_menu'    => 'default',
          'cache_update'        => 'default',
          'cache_menu'          => 'menufilter',
          'cache_filter'        => 'menufilter',
          'cache_path'          => 'path',
          'cache_form'          => 'form',
          'cache_imageinfo'     => 'form',
          'cache_block'         => 'block',
          'cache_views'         => 'views',
          'cache_views_data'    => 'views',
          'cache_page'          => 'content',
          'cache_content'       => 'content',
          'cache_apachesolr'    => 'apachesolr',
          'session'             => 'sessions',
          'users'               => 'sessions',
);

Memcached daemon startup options:

daemon --pidfile /var/run/memcached/memcached.pid memcached -d -p 11211 -u memcached -m 128 -P /var/run/memcached/memcached.pid

Comments

rjbrown99’s picture

rjbrown99 commented
Component: memcache-lock.inc » Code

Fixing component since this is general.

Alex Andrascu’s picture

Alex Andrascu commented

not sure what this means ?! Is this module working as 6.x-1.x-dev at all ?
I think i've tried all possible solutions.
I know the server configuration is deffinitly working see #1328470: No hits no gets no sets. Memcache doesn't complains though

FYI
Using memcached-1.4.9

Installed packages, channel pecl.php.net:
=========================================
Package  Version State
APC      3.1.9   stable
memcache 2.2.6   stable
rjbrown99’s picture

rjbrown99 commented

Yes, module works fine with pecl-memcache and memcache.protocol=ascii.

The linked issue does not specify the .ini settings for protocol mode. Since protocol defaults to ascii, that would be consistent with my findings so far - it works with ascii, not with binary.

I have not yet found any reports of pecl-memcache + memcached compatibility issues for binary mode but I'm still looking.

Alex Andrascu’s picture

Alex Andrascu commented

It's set to ascii (default) and the memcache installation it works as i've mentioned in #1328470: No hits no gets no sets. Memcache doesn't complains though but the module itself isn't doing anything for a reason.

rjbrown99’s picture

rjbrown99 commented

#4 I am not asking you for questions on your setup nor am I attempting to help you troubleshoot your setup. I am reporting my own, independent issue as described in my initial post. If you have thoughts that are relevant to this issue you are welcome to chime in, otherwise please keep the other issue's comments to that thread. Thank you.

catch’s picture

catch
he/him
Primary language English
commented

Based on the above, would it be fair to assume that binary mode with pecl-memcache has not yet been tested or implemented?

I've definitely not tested pecl-memcache + binary. Not sure about Jeremy.

jeremy’s picture

jeremy commented
Priority: Normal » Major

Running pecl-memcache + binary is a currently untested configuration for the Drupal memcache module. Patches welcome!

Marking as major; should be addressed before the next release.

rjbrown99’s picture

rjbrown99 commented

Thanks, I was initially thinking that it might have something to do with the pecl-memcache + memcached binary compatibility since the former is not updated on a very frequent basis. I did notice they changed the class to MemcacheClass. I'll do a bit of digging to see if I can learn more about what might be required to implement this.

jeffsheltren’s picture

jeffsheltren commented

I'm having problems with pecl-memcache using binary protocol, even with a very basic example such as given here http://php.net/manual/en/memcache.examples-overview.php while the same code works fine when pecl-memcache is configured to use ascii mode.

Debug from running memcached with -vv outputs only the following with the example code above:
<35 new auto-negotiating client connection
35: Client using the binary protocol
<35 connection closed.

The Drupal memcache module seems to get a bit further along, but is unsuccessful at storing any variables (per the original bug description):
<35 new auto-negotiating client connection
35: Client using the binary protocol
<35 Read binary protocol data:
<35 0x80 0x00 0x00 0x0f
<35 0x00 0x00 0x00 0x00
<35 0x00 0x00 0x00 0x0f
<35 0x00 0x00 0x00 0x00
<35 0x63 0x61 0x63 0x68
<35 0x65 0x2d 0x76 0x61
<35 connection closed.

I'll continue digging, but wanted to comment that perhaps this isn't a bug within the Drupal memcache module, but a problem with pecl-memcache using binary protocol.

jeremy’s picture

jeremy commented

@JeffSheltren: Which version of the PECL memcache extension are you testing with?

jeffsheltren’s picture

jeffsheltren commented

I tested with the Fedora 15 package: php-pecl-memcache-3.0.5 (this is with php 5.3.8). Also tested on CentOS 5 using the IUS php53u packages, including php53u-pecl-memcache-3.0.6

Both had the same results. memcached is 1.4.7 on Fedora 15, and 1.4.5 on CentOS 5.

rjbrown99’s picture

rjbrown99 commented

I also tried with Fedora 15 and pecl-memcache-3.0.5. There is also a vague reference here to binary mode not working. I also have suspicions that binary mode alone isn't working.

Might be worthwhile to do a simple test outside of Drupal.

jeffsheltren’s picture

jeffsheltren commented

@rjbrown99, yes I tested both in Drupal and with a standalone script -- see Example #1 here http://php.net/manual/en/memcache.examples-overview.php

One thing I noticed is that the IUS php53u-pecl-memcache package does not include even a commented out setting for memcache.protocol in their memcache.ini file. Not sure if that was intentional on their part or not.

j0rd’s picture

j0rd commented

For me, runing latest and greatest versions of D7-memcache-stable, memcache, php-memcached, libmemcache, igbinary and I'm seeing ~500ms extra per page load when binary is enabled. Looking through xhprof logs, it appears that memcached is never able to perform a successful get and thus does cache_sets on each request.

Something is certainly wrong and at the very least, should be mentioned in the README.txt.

japerry’s picture

japerry
Location KOMK
commented
Status: Active » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.