Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Pocache, preemptive optimistic caching for Go

github.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Show HN: Pocache, preemptive optimistic caching for Go

#11

Post by kbolino »

serialx wrote: post #5

PSA: You can also use singleflight[1] to solve the problem. This prevents the thundering herd problem. Pocache is an interesting/alternative way to solve thundering herd indeed! [1]: https://pkg.go.dev/golang.org/x/sync/singleflight

I'm confused by the decision in DoChan to return a channel (instead of accepting one supplied by the caller) and then, given that, also not to close that channel (is something else going to be sent to the channel in the future?). Both seem like strange/unnecessary design decisions.

Re: Show HN: Pocache, preemptive optimistic caching for Go

#14

Post by iudqnolq »

bww wrote: post #6

You may be interested in Groupcache's method for filling caches, it solves the same problem that I believe this project is aimed at. Groupcache has a similar goal of limiting the number of fetches required to fill a cache key to one—regardless of the number of concurrent requests for that key—but it doesn't try to speculatively fetch data, it just coordinates fetching so that all the routines attempting to query the…

Is groupcache suitable for current use? I don't see commits in years and the issues have reports of panics due to bugs.

Re: Show HN: Pocache, preemptive optimistic caching for Go

#15

Post by ecnahc515 »

Thaxll wrote: post #7
bww wrote: post #6

You may be interested in Groupcache's method for filling caches, it solves the same problem that I believe this project is aimed at. Groupcache has a similar goal of limiting the number of fetches required to fill a cache key to one—regardless of the number of concurrent requests for that key—but it doesn't try to speculatively fetch data, it just coordinates fetching so that all the routines attempting to query the…

It's using singleflight which was later on added to the Go std lib: https://github.com/golang/groupcache/tree/master/singlefligh... https://pkg.go.dev/golang.org/x/sync/singleflight

Just a note that `x/sync` is not part of the Go std lib.

Re: Show HN: Pocache, preemptive optimistic caching for Go

#16

Post by NovaX »

bnkamalesh wrote: post #10
zimpenfish wrote: post #3

Earlier quoted context omitted.

> if I initially got the key "foo" at time T=00:00:00, this library would re-query the backing system until time T=00:00:60? even if I requery it at T=:01? From what I understood of the README (10 minute expiry, 1 minute window) only cache requests between 09:00 to 09:59 will trigger a pre-emptive backing fetch. ie. T0-539 seconds uses the first query (no re-fetch), T540-599 does a pre-emptive re-fetch (as long as no…

@zimpenfish yes you are right. refetch is initiated on the first Get between 9-10mins, and the timer is reset as soon as the back fetch is successful

One optimization for background refresh is coalescing the individual reloads into a batch operation based on a time/space window. Here is how we do it in the Java world. [1]

[1] https://github.com/ben-manes/caffeine/tree/master/examples/c...

Re: Show HN: Pocache, preemptive optimistic caching for Go

#17

Post by stock_toaster »

iudqnolq wrote: post #14
bww wrote: post #6

You may be interested in Groupcache's method for filling caches, it solves the same problem that I believe this project is aimed at. Groupcache has a similar goal of limiting the number of fetches required to fill a cache key to one—regardless of the number of concurrent requests for that key—but it doesn't try to speculatively fetch data, it just coordinates fetching so that all the routines attempting to query the…

Is groupcache suitable for current use? I don't see commits in years and the issues have reports of panics due to bugs.

Indeed. It also looks like there is a maintained fork[1], but no clue with regards to the quality.

[1]: https://github.com/golang/groupcache/issues/158#issuecomment...

Re: Show HN: Pocache, preemptive optimistic caching for Go

#18

Post by bnkamalesh »

indulona wrote: post #13

I have implemented my own SIEVE cache, with TTL support. It solves all these issues and requires no background workers. Author, or anyone else interested in this, should read the SIEVE paper/website and implement their own.

interesting, will check out

Re: Show HN: Pocache, preemptive optimistic caching for Go

#20

Post by neild »

kbolino wrote: post #11
serialx wrote: post #5

PSA: You can also use singleflight[1] to solve the problem. This prevents the thundering herd problem. Pocache is an interesting/alternative way to solve thundering herd indeed! [1]: https://pkg.go.dev/golang.org/x/sync/singleflight

I'm confused by the decision in DoChan to return a channel (instead of accepting one supplied by the caller) and then, given that, also not to close that channel (is something else going to be sent to the channel in the future?). Both seem like strange/unnecessary design decisions.

Returning a channel avoids questions of what happens if sending to a caller-supplied channel blocks. DoChan returns a channel with a single-element buffer, so a single send to the channel will always succeed without blocking, even if the caller has lost interest in the result and discarded the channel.

DoChan doesn't close the channel because there isn't any reason to do so.

Post reply on HN