ReneB
commented
4 years ago 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).
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.pyfile. 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.