3 ms·
But then some process on the server has to fetch multiple files from the repository each time there's a request. It seems this solution consists in getting aro
by p4bl0 3y ago
But then some process on the server has to fetch multiple files from the repository each time there's a request.
It seems this solution consists in getting around doing a bit of work when it is actually necessary (on website update) by doing a lot of work over and over.
- Karellen 3y agoFTA: > This sounds like a lot of steps to serve a single file, but there's two key optimizations which can be made. The first is to cache the root tree's hash in memory, which skips two lookups right at the beginning. The root tree's hash will only change when the latest commit of the branch changes, so it's enough to cache it in memory and have a separate background process periodically re-check the latest commit. > The second optimization is to cache tree objects in-memory using their hash as a key. The object identified by a hash never changes, so this cache is easy to manage, and by caching the tree objects in memory (perhaps with an LRU cache if memory usage is a concern) all round-trips to the remote server can be eliminated, save for the final round-trip for the file itself. Also, the "background process periodically re-check the latest commit" seems like a bit of overkill if the repo is local; just caching and checking the mtime of `refs/heads/main` should be enough to decide whether the root tree needs re-reading.