Skip to content
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

Proposal: cache the /list endpoint for a short period of time? #893

Closed
arschles opened this issue Nov 10, 2018 · 5 comments
Closed

Proposal: cache the /list endpoint for a short period of time? #893

arschles opened this issue Nov 10, 2018 · 5 comments
Labels
hosting Work to do to improve/change how we host the services proposal A proposal for discussion and possibly a vote

Comments

@arschles
Copy link
Member

Is your feature request related to a problem? Please describe.

The /list endpoint contacts the upstream VCS to get version numbers, so that corresponds to one git (or hg etc...) operation per dependency. For a public deployment of athens, I believe that's untenable.

Describe the solution you'd like

I think it'd be a good idea to add an option to the proxy to cache the /list endpoint. That would mean that it fetches the version list directly from storage until a TTL expires. At that point it would do the list request to the upstream once, refresh storage, and reset the TTL. If there are multiple proxy servers running in a cluster, they would use #760 to ensure only one refresh is done after the TTL.

If we did this, we would need to tell package authors that if they push a new commit or release a new tag, it won't show up in Athens until the TTL expires. We could let them trigger a refresh for their module with #104, but I'm not sure if that's a reasonable solution.

Describe alternatives you've considered

I haven't thought of anything else that would reduce upstream requests for each /list call.

Additional context

I'm researching and preparing for #772 and found that some way to tell whether a response was cached or not would be really helpful for us.

@arschles arschles added hosting Work to do to improve/change how we host the services proposal A proposal for discussion and possibly a vote labels Nov 10, 2018
@ghost
Copy link

ghost commented Nov 12, 2018

I think some level of caching would be a big bonus here. Could we have manual invalidation on new version pushes?

@arschles
Copy link
Member Author

@robjloranger yea, I think we could definitely have that. Maybe some variation on the webhook that got proposed in #104 could do the invalidation - what do you think?

@ghost
Copy link

ghost commented Dec 1, 2018

Exactly 😁 some endpoint to say some module was "updated" and we can even check to see if it does have a new version, and if so update the list cache.

@arschles
Copy link
Member Author

arschles commented Apr 3, 2019

Update: #1068 is the endpoint that @robjloranger talks about in #893 (comment)

I am going to start prototyping this now

@arschles
Copy link
Member Author

We've discussed this a few times and decided this caching logic shouldn't live inside of Athens. We are discussing an "offline mode" in #1506, which will treat the list endpoint as immutable. If Athens gets an offline mode, then caching will become unnecessary if you run it in that configuration. If you were to still run it in online mode configuration and still want caching, the best thing to do would be to use a caching proxy. There are several widely used open source ones and several cloud based ones. I have also built a "toy" one here for reference.

I am going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hosting Work to do to improve/change how we host the services proposal A proposal for discussion and possibly a vote
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant