Closed (fixed)
Project:
Memcache API and Integration
Version:
5.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
9 Apr 2007 at 21:53 UTC
Updated:
28 Jun 2007 at 05:13 UTC
Just installed the latest dev release, moved memcache.inc over to includes, chowned and chmodded it correctly, modified settings.php appropriately, I'm only running one memcache server so I didn't include config for the server specifically. Enabled caching, enabled the memcache module and then logged out.
When I refresh any page on the site now it just comes back empty. Did I miss something? I tested the php->memcache with a little script manually setting an object so I know that is working. Thanks for your help!
Comments
Comment #1
lyricnz commentedPlease check your webserver error logs. There's probably a typo somewhere in your configuration, which causes a PHP error.
BTW, if your memcached server is (only) localhost:11211, you don't need to modify the settings.php at all.
Comment #2
lyricnz commentedCorrection, you don't need to configure the memcached servers in settings.cfg. You still want to configure memcache to replace the standard cache. There is actually a bug in the documentation about this (I'll fix it now). Your configuration should look something like (note the name of the last attribute)
The error may be that your webserver is missing the memcache PECL extension, but see your error log.
Comment #3
lyricnz commentedComment #4
bajakan commentedok excellent I changed the config from memcache_inc to cache_inc, here is what my error log is showing:
[Tue Apr 10 09:34:17 2007] [error] [client 24.153.142.26] PHP Notice: Undefined property: stdClass::$cache in /var/fancrush-promo/fancrush/webroot/includes/memcache.inc on line 241
[Tue Apr 10 09:34:17 2007] [error] [client 24.153.142.26] PHP Fatal error: Call to undefined function drupal_add_js() in /var/fancrush-promo/fancrush/webroot/sites/all/modules/memcache/memcache.module on line 8
[Tue Apr 10 09:34:17 2007] [error] [client 24.153.142.26] PHP Notice: Undefined property: stdClass::$cache in /var/fancrush-promo/fancrush/webroot/includes/session.inc on line 77
Thanks for your help, I'll also continue to investigate
Comment #5
bajakan commentedok I commented out the line 8 from memcache.module and it seems to be working now. I also checked common.inc and found the method that its referring to, drupal_add_js(), so I'm not sure why its unavailable.
Comment #6
lyricnz commentedThat's strange. Which version of Drupal are you using?
Comment #7
robertdouglass commentedbajakan, are you using the memcached sessions include file as well? Or, are you using the bootstrap.inc patch that used to be in the module? Somehow some weird error in the order of bootstrapping seems to be occurring, namely, memcache.module is getting included before common.inc. This isn't supposed to happen under any circumstance, so we need to find out exactly how it is happening.
Comment #8
bajakan commentedI don't have a memcache sessions include file, I'm not using any bootstrapping from the previous version either. Do I need to install another file? I'll try to be on IRC if we can chat, we can figure it out. I'm also only seeing a ratio of 1hit:2miss max when load testing the site, could be related to this. I'll grab the latest snapshot 1.x-dev from yesterday.
Comment #9
bajakan commentedOK I absolutely verified that bootstrap.inc is the same as the current 5.1 drupal download. I noticed that it only includes common.inc when phase is DRUPAL_BOOTSTRAP_FULL. I'm not sure here, but I do have caching enabled, figured that had to be enabled to hit memcache or to get any of the modules using the normal cache api to work. Perhaps that's the wrong cache setting? or I'm missing another setting?
Comment #10
bajakan commentedok one more! in _drupal_cache_init I have this code:
So it seems correct that init gets called before common.inc is included.
Comment #11
jamesJonas commentedNote#5
I have been working on the benchmark.txt file by running 'siege' on the latest memcache dev version (4/12/07) and ran into this error:
[Fri Apr 13 17:03:56 2007] [error] [client 127.0.0.1] PHP Fatal error: Unknown function: drupal_get_path() in /var/www/html/drupal_bench51/modules/memcache/memcache.module on line 8
What was stranger is later in the run (16 concurrent users hitting for 1 minute) I get this error:
[Fri Apr 13 17:04:07 2007] [error] [client 127.0.0.1] PHP Warning: mysqli_error() [function.mysqli-error]: invalid object or resource mysqli\n in /var/www/html/drupal/includes/database.mysqli.inc on line 65
I also observed that the first instance of the retieval of the node went great. But the second time the same node was retrieved 0 bytes was returned (same as a blank page).
To resolved this error I had to 'restart' the db.
I then shut off memcache, (commenting out settings.php memcache config) re-ran siege, no errors. Turned on memcache, error repeated. This may mean that under a high stress situation communication via mysqli to the database fails. I'm still trying to figure it out... hope this helps?
Comment #12
bajakan commentedI had other errors as well after the Fatal error on line 8 of the module, but didn't consider them valid because that error would cause all kinds of problems, if memcache module doesn't get init'd then who knows what else will fail. I haven't actually stepped through the startup sequence in its entirety but by inspecting bootstrap.inc, I can see that its definitely possible that common.inc will not be included at the time the module's init method is called.
I'm using Drupal 5.1.
Comment #13
robertdouglass commentedWell, the offending code is just the debug stuff, and there are other ways to get the job done, so I'll take a different approach. Feel free to turn the memcache module off at this point... it is just handling debug info stuff.
Comment #14
bajakan commentedvery much appreciated! Our initial stats showed 1hit -> 3 misses, not that impressive and we were able to handle 100 registrations per minute pretty easily along with other page views and actions of those users on the site. After hacking up the block module to cache blocks that ratio went to 1:1 and we kicked up to supporting 200 concurrent users with no errors on the site. That's 200 concurrent users all spamming the box using a load test tool with a small random delay between requests.
Thanks! Good job!
Comment #15
lyricnz commentedThis issue is more-than-likely related to a PHP error when the memcache.module was a bit broken for a while. Please retest, and reopen if it's still an issue (I haven't seen it recently)