Thanks for the mentioning the caveats with memcachefs. I’ve only used it a few times during development and it does seem very unreliable. When it works, it seems to work OK, but it often just refuses to mount altogether. Seems like maybe it could use a little more time in the oven…

As for my complaints about memcache in general, you make some good points; here at Logic Supply we’ll end up having a relatively low number of cached items so doing a “table scan” would probably not adversely affect our performance, but I can certainly understand how it would on sites with much larger caches. Like you mention, if necessary it’s not that difficult to add some sort of key tracking or reporting in a wrapper layer. I’m just lazy by nature so I in general I just want everything to work the way I expect it to

memcachefs) Be super careful about using this one, in fact I’d highly recommend against it. It’s a nice proof of concept but real world performance would be terrible.

A few reasons after a cursory glance at it:
1) It doesn’t appear to handle nonblock very well. Get two queries going at once and you might be screwed.
2) It relies on libmemcache (not the recent libmemcached), which does totally awesome things such as call ‘exit()’ and ‘assert()’ during some error conditions.
3) The “directory listing” it does uses an internal slab debugging command. It’s very slow and truncates the data it displays, so if you were to rely on it and your data became larger than a couple dozen variables, you’d be screwed.

I do kind of wish there were more extended memcached libraries now Namespacing, lists, troubleshooting, etc, are all common enough operations that many good examples should just already exist.

Consider it a good thing we’ve resisted adding a keys dump for so long! Like sometimes when learning a new language, you have to adjust your expectations a little. The common debugging idea might be to dump all keys and inspect what’s there, but it’s just as easy (albeit different) to add a debugging mode to your abstraction to count hits/misses. Must more flexible, and performant!

Memcached is fast because it lacks many database concepts (such as multiversioning), so the idea of doing a “Table scan” on potentially millions of keys is something we would prefer folks not build into applications by accident. Imagine how grumpy people would be if they built their fancy new toy with that “super scalable” memcached thing and it _still_ broke after they got a half million keys in it Tsk tsk!

That being said, I believe ‘tag’ support is actually on the way this time, which should help with namespacing complexity.