-
Notifications
You must be signed in to change notification settings - Fork 7
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
WIP caching #166
base: master
Are you sure you want to change the base?
WIP caching #166
Conversation
@kvigen @samfishman this morning @Sayan- and I added cache hit/miss logging to this. I think we can use https://github.com/die-net/lrucache as the cache implementation, since this will give us byte-size limiting and also some nice-to-have LRU eviction logic. I think the next steps from here:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good!
have we vetted https://github.com/die-net/lrucache carefully? it doesn't have a ton of github stars and lru cache performance can be tricky. an alternative might be: https://github.com/karlseguin/ccache, but i don't know how difficult that will be to integrate with httpcache
also, thinking more about app-service + HM, i'm realizing that we have a challenge that when someone makes a change in HM they expect to see the change show up immediately. Not sure if there this is going to cause problems with the endpoints we're thinking about, or whether we should think about that case too
@@ -1,5 +1,3 @@ | |||
// Code generated by go-swagger; DO NOT EDIT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i assume this is from a go-swagger update?
require.NoError(t, err) | ||
} | ||
require.Equal(t, controller.getCachedCount, 2, "expected a second request to go through") | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extra line
type cacheHitCounter struct { | ||
httpcache.Cache | ||
hits int64 | ||
misses int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably not worth it yet, but i could see us wanting to know this on a per-endpoint basis
@@ -191,6 +191,20 @@ COPY bin/my-wag-service /usr/bin/my-wag-service | |||
that exposes `map`, `forEach`, and `toArray` functions to iterate over the | |||
results, again requesting new pages as needed. | |||
|
|||
### Caching | |||
* Wag can add `max-age` cache-control headers on respones if you use the `x-caching` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: mention that max-age is in seconds
operationId: getBookByIDCached | ||
description: Retrieve a book | ||
x-caching: | ||
max-age: 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it make sense to make this 1 so the tests run more quickly, or does that make the tests unstable?
adds a
x-caching
extension that you can configure endpoints with. Only supports addingmax-age
headers on responsesadds caching support go clients via https://github.com/gregjones/httpcache
not done:
gregjones/httpcache
has an in memory cache we could use, but it doesn't limit the size of the cache in any way.wag
should probably wrap this to have a limitwag
should report a counter of cache hits/missescaching in the js client 😨