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 <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.
>
>
--
---
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.1909231337250.620%40dskull.
