-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
understanding the performance characteristics of bounded cache #3530
Comments
These aren't suitable e.g. for running in CI since some take far too long (and an impossibly long-time when running under criterion's normal bootstrapping sampling regime. We might try to improve this ourselves: haskell/criterion#218 An initial summary analysis will be in hasura#3530.
These aren't suitable e.g. for running in CI since some take far too long (and an impossibly long-time when running under criterion's normal bootstrapping sampling regime. We might try to improve this ourselves: haskell/criterion#218 An initial summary analysis will be in hasura#3530.
@0x777 The most interesting parts have little to do with the mechanics of caching per se (overhead of LRU bookkeeping, or insert time), and much more to do with how effective caching is and how the various parameters interact (the "realistic" benchmarks below). MicrobenchmarksMicrobenchmarks of lookups; not very interesting
Inserts; mostly fine but evicting is somewhat expensive
Here we can see an evicting insert is on average ~3us which is relatively
"Realistic" benchmarksHere we do more "realistic" tests of the cache under the assumption that These benchmarks loop over 1-million zipf-distributed values doing:
These can be used to help determine how different caching/eviction policies NOTES:
Realistic load, no miss costThese just measure the latency of the caching machinery itself (as well as These number are about what we'd expect based on the microbenchmarks above
Realistic load, with a realistic cost of a cache miss(The format here is different because these were too slow to run with
Realistic load, optimized cache miss cost (1ms)The same as above, but a smaller cost for a cache miss.
Observations and TODOsObservations:
TODOs and action items (we can open issues for these, and edit them in here):
|
These aren't suitable e.g. for running in CI since some take far too long (and an impossibly long-time when running under criterion's normal bootstrapping sampling regime. We might try to improve this ourselves: haskell/criterion#218 An initial summary analysis will be in hasura#3530.
…-bounded-cache-performance Understand bounded cache performance. Closes #3530
These aren't suitable e.g. for running in CI since some take far too long (and an impossibly long-time when running under criterion's normal bootstrapping sampling regime. We might try to improve this ourselves: haskell/criterion#218 An initial summary analysis will be in hasura#3530.
@0x777 said :
What's the difference in metrics like req/s and latency? Does it warrant extra work to improve the data structures used?
The text was updated successfully, but these errors were encountered: