Closed (works as designed)
Project:
Memcache API and Integration
Version:
6.x-1.7
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
26 Nov 2010 at 10:58 UTC
Updated:
12 Jun 2013 at 14:29 UTC
Jump to comment: Most recent file
Comments
Comment #1
greenrover33 commentedComment #2
catchPlease post a diff - see http://drupal.org/patch/create
Comment #3
greenrover33 commentedHello catch,
i completly rewrote the memcache.inc please the the file in tar.gz file.
And for the dmemcache.inc i attached a patch file.
Thanks Heiko
Comment #4
jeremy commentedThe odds of this being reviewed is very low unless you include a diff. If every line in the file really changed, so be it, a diff is still requested.
Comment #5
longwaveHad a quick look at this. It stores all known cache keys in a global, which is loaded at the start of each request and resaved into memcache in a shutdown handler. This means partial wildcard flushes can be done accurately, but in theory this would use lots of memory on a large site with thousands or millions of cache items. However, it appears this would be mitigated by the fact memcache can only store 1MB in a single entry - so as soon as the list of cache keys gets too large, it looks like this will fail entirely.
This may still be worth investigating; perhaps using a hybrid approach on a per-table basis, where small cache tables store their known keys and can avoid multigets, but larger cache tables use the multiget approach. This would make the design and configuration even more complex, and I'm not sure how you would determine which caches should use which method - and do most smaller cache tables ever suffer from partial wildcard clears?
It also switches the long key hashing algorithm from SHA1 to MD4, which is worth considering too (along with MD5) - speed is more important than security in this instance - though I'm not convinced this will make much difference in real world usage.
Comment #6
catchThe original wildcard logic stored all wildcard flushes in a variable, which sounds somewhat similar - and that immediately falls down if you have wildcard flushes by $nid or similar since you could have tens of thousands (or millions) of nodes which eventually get flushed and fill up that variable.
I'm very surprised that this is saving 20% of cpu time, since I've not been able to measure memcache using more than around 10% of time, including the actual memcache calls as well. If you could post xdebug or xhprof output to show where the extra time is being spent that'd be useful.
Comment #7
greenrover33 commentedHy Cache,
here a XhProf run with my patch.
My problem ist that we need modules like:
Pathauto -> Url alter -> Path Cache
Domain Alias -> Domain Access -> Domain Source
with would need massiv cache requests.
Ant the problem with your version is the call of "memcache_wildcard_flushes" in "cache_get" with need the 20% i can save with my version. Because if oyu use "memcache" not "mecached" you dint have a multi query.
This means a lot of not need querys on each positiv get.
And i neve found a use something like this
cache_clear_all(3345434, 'node');
I only found use like:
cache_clear_all('*', 'node');
@longwave
thanks, very nice tips, i will use them.
Comment #8
markpavlitski commentedPlease provide an up-to-date patch for this issue.
Comment #9
markpavlitski commentedNo activity for 2 years and there have been a number of fixes/ improvements since then. Marking closed.