Listing all keys on a server: why?
fabian at toomuchmedia.com
Thu Jul 27 17:20:47 UTC 2006
what I do not understand about these discussions that CONSTANTLY go on
in this list (it is one of the most common questions my oppinion, or at
least a version of it) is that amount of time spent discussing this back
and forth has taken 5 times longer by now than simply adding the feature
to memcached. Its not a HUGE deal to crawl the tree for all key names
and just dump them, no need to sort them or anything, just dump them.
If someone thinks they need this, let them use it and if you think it
would never be usefull then let them fail at it, it would remove 50% of
the traffic this list sees day in and out though...
In certain cases such a list is usefull.
session management via memcached.
Lets pretend you use memcached stored sessions in php, you know your
memcached has 64MB of data and you know you have session load at any
given time of about 5000 sessions each day. Each session takes 1000
bytes of data, which alrady is a good amount for a session, making it
5MB total, PLENTY of room left in memcached that you know that the
session data would not get removed due to no more room TOO soon, it
MIGHT be removed sooner, but not after a minute or even an hour, it will
take long to happen IF it even happends, something you can live with
Now you have a problem though, you want to build a "logged in user
list", best way? get all sessions in memcached, look through each one
and filter out the username.
You could theoretically even add something which would limit the keys
listed depending on the timestamps they have (might not understand
memcached enough though, so not sure if this definately works) which
would limit the sessions you need to heck since you only want the ones
used in the past 10 minutes.
Brian Moon wrote:
> Jamie McCarthy wrote:
>> ...the list you would get would be obsolete as soon as you got it. So
>> my guess would be that, if you think you need that list, you may be
>> wanting to do something with memcached that you can't really do. But my
>> guesses are frequently wrong and if there's something I'm forgetting
>> please email me and let me know. Thanks.
> I see no reason to take this off list. Lets hash it out here.
> At the BoF last night, I talked with some guys that need/want that.
> They had valid reasons. Not sure if they are on the list or not, but
> they had some valid arguments for their business. Now, you could say
> that they are using memcached for something it was not made for, but
> the problem is that there is not anything better to use in its place.
> Brian Aiken spoke last night at the BoF about NDB (the backend to
> mysql cluster) and using it directly, skipping the mysql part. That
> could be a good solution for some people that need more control and
> redundancy. However, there is no PHP/Perl/Python, etc. interface for
> it at this time.
More information about the memcached