You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things we are currently missing in this implementation is a cache, and one of the lessons we learned (or maybe just an opinion I have) about ccc-server is that having an active cache-management solution is a nice feature. Examples include frog-pond/ccc-server#50 ("cache poking") and discussions I think we have had about
For example, in frog-pond/ccc-server#638, we had to switch from a lightweight implementation to a heavier one that involved HTML parsing. It would be nice, imo, if we had automation in place to continuously fetch for new results.
Some ideas:
Use redis. It's nice and has built-in EXPIRE controls.
redis works well — it also has support for tokio which is good.
Add some kind of background worker infrastructure
Have a mechanism to invoke request handlers outside of the context of a real request
Use a schedule to periodically re-request website content.
Add some kind of early-warning exception system to dump out upstream data and notify us if things change
Could also be used to detect new fields?
Single-flighting? If 1000 clients request the same site at the same time, and the cache is missing the corresponding data, it would be better to request the upstream just once. Use a fork of some sort to prevent accidentally requesting more than once, and in that entire critical section (the time it takes to complete the request) also write into the cache so that the next batch of requests see the new cache entry.
I have some rudiments to start with; just writing up the issue so it is documented.
The text was updated successfully, but these errors were encountered:
One of the things we are currently missing in this implementation is a cache, and one of the lessons we learned (or maybe just an opinion I have) about
ccc-server
is that having an active cache-management solution is a nice feature. Examples include frog-pond/ccc-server#50 ("cache poking") and discussions I think we have had aboutFor example, in frog-pond/ccc-server#638, we had to switch from a lightweight implementation to a heavier one that involved HTML parsing. It would be nice, imo, if we had automation in place to continuously fetch for new results.
Some ideas:
EXPIRE
controls.redis
works well — it also has support for tokio which is good.I have some rudiments to start with; just writing up the issue so it is documented.
The text was updated successfully, but these errors were encountered: