I am on the caching team in Box and I'm thinking about this potentially as part of a mechanism for hot key mitigation rather than for general use for all gets. Assuming I have a mechanism for detecting hot keys and notifying clients about them, I believe the clients could mitigate the impact of hot keys using a small local cache for these cache entries but I would still want to ensure the clients are not using stale data from the local cache. Using mget in either of the ways we talked about before would work for this scenario, but having the "fetch if cas does not match" flag would avoid the second round trip in the case that the value changes.
Cheers, John On Sun, Sep 22, 2019 at 12:20 AM dormando <dorma...@rydia.net> wrote: > Can you give me more background on your workload? > > Correct me if I'm wrong but your aim was to use a local cache but check > the memcached server on every fetch to find out if it's valid? > > If your objects are less than... like a kilobyte that's actually slower > than not having the local cache at all. Think you need to be in the 32k+ > range to start seeing benefits. > > Best is to time bound it, at any rate. Max 1 validations per second for > hot keys that get X requests per second each. > > I'm going to draft out two possible mget flags to see if they'd not be > overcomplex: > > - Return value if CAS match > - Return value if CAS not match. > > ... the latter of which would do what you want, but lets just take a quick > look at your workload first so you don't end up with something more > complicated and slower :) I'm not sure I can get the flags to make sense > but I'll try. > > On Sat, 21 Sep 2019, John Reilly wrote: > > > 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 > . > > > > > > -- > > --- > 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.1909220016480.620%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-9fabQis9f-0QJFCk%2B08Rc4JTjsVeqjOdcSr9jYnk-bg%40mail.gmail.com.
