Re: get value, but only if cas token is not the provided one
> > > That is a really nice idea - I'll definitely have to explore it. An > effective hot cache like this may reduce or eliminate the need for mitigating > specific keys. We could > incorporate size into it so that larger values get a higher weighting. > First one's free :) I found some other weirdness with the last access time, but I'm pretty sure it's fixable so this pattern should work once released. -- --- 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.1909240012050.620%40dskull.
Re: get value, but only if cas token is not the provided one
On Mon, Sep 23, 2019 at 1:48 PM dormando wrote:
> Gotcha. Thanks a ton for reaching out and putting up with my questions :)
>
Not at all :) - thank you for all your work on memcached.
mget/mset/mdelete will certainly be a great addition.
> One other thing mget might get you here is an easy probabilistic hot
>
cache. I really like probabilistic algorithms since they require low or
> zero coordination :)
>
> With mget, you could:
>
> `mget foo slhvfc` etc
>
> s = size, required kind of :)
> l = last access time (fixing this in the PR today)
> h = if the item's been hit before (also being fixed today)
> v = value
> f = client flags (if you need them)
> c = cas value, for your later comparison/check
>
> Then for your hot cache:
>
> if (hit && "last access is < 5 seconds" && random(1000) == 1) {
> insert_into_localcache(obj);
> }
>
> to autotune, that 1000 becomes a variable you sync out periodically (or
> simply stick in the local cache for 60 seconds unconditionally),
> decreasing or increasing to match a target hit ratio on the local cache.
>
That is a really nice idea - I'll definitely have to explore it. An
effective hot cache like this may reduce or eliminate the need for
mitigating specific keys. We could incorporate size into it so that larger
values get a higher weighting.
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-adkKOTf8%3Du3qX0RW_4zSeH%2B6ZusGiYgLex8-5y9wgcA%40mail.gmail.com.
Re: get value, but only if cas token is not the provided one
Gotcha. Thanks a ton for reaching out and putting up with my questions :)
I'm still a little concerned that this setup would be slower since you're
blocking on the check to mc before using the local cache, but you know
your workload best :) This would still be a win if the cache objects are
very large, or CPU intensive to deserialize and the local cache held
deserialized objects.
I'll take a look today at the value flag. It's come up enough times, just
need to keep the logic clean internally.
One other thing mget might get you here is an easy probabilistic hot
cache. I really like probabilistic algorithms since they require low or
zero coordination :)
With mget, you could:
`mget foo slhvfc` etc
s = size, required kind of :)
l = last access time (fixing this in the PR today)
h = if the item's been hit before (also being fixed today)
v = value
f = client flags (if you need them)
c = cas value, for your later comparison/check
Then for your hot cache:
if (hit && "last access is < 5 seconds" && random(1000) == 1) {
insert_into_localcache(obj);
}
to autotune, that 1000 becomes a variable you sync out periodically (or
simply stick in the local cache for 60 seconds unconditionally),
decreasing or increasing to match a target hit ratio on the local cache.
This is similar to how extstore decides to recache objects. It's been
working well in production workloads.
It should also be possible to make that check only against objects which
you think could be hot (so not user level stuff I'd guess), reducing the
bytes on wire a bit.
On Mon, 23 Sep 2019, John Reilly wrote:
> 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 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 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
Re: get value, but only if cas token is not the provided one
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 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 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 > > > > > > -- > >
Re: get value, but only if cas token is not the provided one
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 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
Re: get value, but only if cas token is not the provided one
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 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.
Re: get value, but only if cas token is not the provided one
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.
