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

Clear ETag cache when server is restarted #109

Open
matthijskooijman opened this issue Jun 10, 2020 · 1 comment
Open

Clear ETag cache when server is restarted #109

matthijskooijman opened this issue Jun 10, 2020 · 1 comment

Comments

@matthijskooijman
Copy link
Member

Currently, the ETag caching header used by the FinalCheck view is based on update timestamps of objects used, plus some additional data, so it changes whenever one of these objects changes.

However, this ETag should really also include the "code identity", i.e. when the code or a template changes, the produced output might also change, so the ETag should be changed (invalidating the browser-side cache).

Creating a full hash of all used code on every startup is obvious, but would significantly slow down startup and is not entirely trivial to implement.

A simpler approach would be to include a server startup time in the ETag. This means that whenever the server is restarted, the ETag changes. This might cause more invalidation than strictly needed, but that's ok.

Just setting a timestamp at startup and using that will probably not work, though, since then multiple workers might end up with different timestamps and switching between multiple workers would keep invalidating the cache (there is a chance that the UWSGI forking module causes the timestamp to be set once for all workers, but that seems fragile to rely on).

So, I would suggest looking at the timestamp of the arta/uwsgi.py file. In production, this file can be touched to restart the server, so on most restarts, its timestamp will be bumped. In development, you can also just touch this file if needed and restart the server.

To prevent having to access the file on every request, it would be ok to read the timestamp at startup into some global variable or maybe a setting and then use that for every request.

@ReneB
Copy link
Member

ReneB commented Jun 10, 2020

It probably wouldn't cover all cases, but have you also considered using the SHA of the latest git commit as a part of the ETag? That would result in not every restart killing off all the ETags, but instead only if changes were actually made (and committed, so no uncommited hotfixes - which, I feel, is a good thing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants