Hi dormando, Sorry for the delayed response. I finally got a chance to read through https://github.com/memcached/memcached/pull/484 . It sounds great.
In my case, I was thinking about using a local cache to mitigate the network impact of hot keys rather than per-request performance reasons, but I was hoping to do that without the clients potentially using stale data from their local cache. It might still be nice to have a flag on mget to fetch the value if it does not match a provided cas, but in the absence of this flag I think it would work fine using mget to only get the cas, and doing a full fetch on cas mismatch. Cheers, John On Tue, Sep 17, 2019 at 5:43 PM dormando <dorma...@rydia.net> wrote: > Hey, > > Check this out: https://github.com/memcached/memcached/pull/484 > > You can't quite do this with the way metaget is now, though it's feasible > to add some "value if cas match on mget" flag. I'd have to think it > through first. > > For local caches though, unless your object is huge, simply waiting on a > round trip to memcached to see if it's up to date removes most of the > value of having the local cache. With a local cache you have to check it > first, then check if it's fresh, then use it. It's likely the same speed > to just not have the local cache at that point so you can avoid the CPU > burn of the initial hash/test or trade it for CPU/network used in pulling > in the value and having a simple system. > > However! If you have a limited size "hot cache" and you can asynchronously > test if they need to update, you could (say once per second or whatever > makes sense for how hot your objects are), kick off an async test which > runs mget with options for no-bump (optionally), no value, and cas (no > flags, size, etc) for a lightweight response of just the cas value. > > If the cas doesn't match, re-issue for a full fetch. This works okay for > high frequency items since an update would only leave them out of sync > briefly. Polling kind of sucks but you'd only do this when it would reduce > the number of requests back to origin anyway :) > > I'm hoping to get metaget in mainline ASAP. Been hunting around for > feedback :) Should be finishing up the code very soon, with merge once a > bit more confident. > > On Tue, 17 Sep 2019, John Reilly wrote: > > > Hi all,I was just thinking it would be great to be able to cache the > most used items in a local cache on the client side and I think this would > be possible if there was a way > > for the client to send a request to get a key, but only if the cas value > is not the same as the cas token of the value I already know about locally > in the client. I don't think > > this is possible with either protocol today, but would be happy if told > otherwise :) > > > > Also, can anyone think of a reason why this would not work - if it is > not supported today, it might be a nice feature to add. > > > > Thanks, > > John > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to memcached+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CAJ__CS_0CaWLU-fqTV%2BeYRU6V3Pg6D8Rix%2B7Lbg_YyDs5tjxPg%40mail.gmail.com > . > > > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1909171732430.1888%40dskull > . > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/CAJ__CS_%3Db8rudQ2v11NjhO5Ldccy5txVo5YrUptdhBuZMKfHGw%40mail.gmail.com.