Write LRU to database

[Chris Hondl]

The conventional wisdom for memcached pretty much lines up with what Steve
and Jeetu have said - only store things in memcached if you keep a
persistent copy of them somewhere else.

Our experience is that you can successful use memcached in two other
scenarios:

1.  Queue of transient messages.  We use memcached for our chat
infrastructure.  Each queue of chat messages goes into memcached.  A client
can connect to any chat server in the pool and send/receive messages.  This
lets us scale chat horizontally across machines without having to have a
affinity for a chat client to a particular server.  Chat messages get
typically get delivered within 1 second, so bouncing a memcached instance
affects only a small number chat messages.

2.  Application level monitoring.  We store large amounts of performance
information into memcached (counts of slow pages and slow queries, counts of
queries per database table, execution traces for slow pages, database
connection info for debugging too many connection errors in MySQL, etc.).
Most these are stored either on slow pages (when a page takes 1+ seconds,
doing an extra couple memcached hits isn't a big deal) or are randomly
sampled so that the expected number of memcached hits per event is small.
If counters get reset or we lose a few execution traces no big deal - worst
impact is that our rrd graphs have blip for five minutes.

You can use memcached for scenarios other than caching objects or database
queries.  You just have to be careful to work within the constraint that
your data will sometimes disappear in one of a handful of pretty well
defined ways.

Anyone else have good memcached application outside of caching?

Chris



On 11/8/06, Steven Grimm <sgrimm at facebook.com> wrote:
>
> Oscar Kené wrote:
> > Is there any functionality to make it write these to a mySQL-database
> > instead?
>
> Memcached is typically used to cache data that's already in your
> database to begin with, in which case this becomes unnecessary; if an
> object isn't in your cache, you just hit the database instead.
>
> In my opinion it is not a good idea to *only* store data in memcached.
> Memcached processes can get killed accidentally, your data center can
> have a power outage, your sysadmins can decide they need to move servers
> to different racks, your memcached machines can have hardware glitches
> and spontaneously reboot, etc. (To name some of the things that have
> happened to our memcached servers.) Even if you modified it to write
> data somewhere else at expiration time, you would still be vulnerable to
> the cache getting blown away for whatever reason; you'd lose all the
> non-expired data.
>
> > Right now my data is INSERTed, SELECTed only once and then DELETEd.
> > But every "set" of data is not handled sequentially. So one "set" of
> > data can be INSERTEd but not SELECTed or DELETEd before the entry is
> > subject to the "LRU-rule". I.e. I want to keep the most recent
> > "INSERTs" in memcache as they are the most likely to be operated on
> > first.
>
> If that's generally your usage pattern, then memcached's LRU semantics
> may not even come into play, assuming you're careful to delete items
> from the cache after you're done operating on them (which should be fine
> if you're only reading them once.) Memcached will always reuse space
> from deleted or expired items before it will evict any valid items from
> the cache, so you just need to have enough space in your cache to hold
> your typical backlog of items. If you're constantly reading and deleting
> the most recent items, then the next items you write will just reuse
> that space over and over again.
>
> FYI, memcached's expiration policy is not strictly LRU if your cache
> items are of significantly different sizes; there is a separate LRU
> queue for each range of sizes computed by the slab allocator. In normal
> operation that's usually not noticeable, but if you're trying to do
> something that depends in any way on eviction order, you'll want to be
> aware of that.
>
> -Steve
>



-- 
http://avatars.imvu.com/chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20061108/eb8275ca/attachment.html