Repository navigation
gomodfs, store/remotestore: fetch less over the network in WinFsp mode - #32
Merged
Merged
Conversation
Two changes that cut HTTP requests from a WinFsp mount to its remote store: Cache metadata files (.info, .mod and .ziphash) in remotestore.Store. They never change for a module version, but every stat and open of one fetched it from the server again, and the go command reads hundreds of them per invocation, mostly one at a time while loading the module graph. Over 8 cached go commands, that was about 13,600 requests at about 1ms each. Like modmaps, they're cached for the life of the Store, with concurrent fetches merged. Misses aren't cached. Fetch a file's contents on its first read rather than when it's opened. Windows opens files for many things that don't read them, including every os.Stat, and each open downloaded the whole file. Opens now get the size and type from the store's (cached) modmap, so an HTTP error fails the first read instead of the open. In a Windows VM with the module cache and Tailscale Go toolchain served from a remote store, fully cached go commands (median of 30, p < 1e-10): go build tailscale.com/cmd/tailscale/cli: 4.90s -> 2.21s go run github.com/tc-hib/go-winres: 2.59s -> 1.58s and the first command after mounting goes from 5.73s to 3.10s and from 2.50s to 1.26s. (On NTFS, both take under 0.3s.) "go mod verify" of all 75 modules of the build still passes over the mount. Updates tailscale/corp#24037 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two changes that cut HTTP requests from a WinFsp mount to its remote
store:
Cache metadata files (.info, .mod and .ziphash) in remotestore.Store.
They never change for a module version, but every stat and open of one
fetched it from the server again, and the go command reads hundreds of
them per invocation, mostly one at a time while loading the module
graph. Over 8 cached go commands, that was about 13,600 requests at
about 1ms each. Like modmaps, they're cached for the life of the Store,
with concurrent fetches merged. Misses aren't cached.
Fetch a file's contents on its first read rather than when it's opened.
Windows opens files for many things that don't read them, including
every os.Stat, and each open downloaded the whole file. Opens now get
the size and type from the store's (cached) modmap, so an HTTP error
fails the first read instead of the open.
In a Windows VM with the module cache and Tailscale Go toolchain served
from a remote store, fully cached go commands (median of 30, p < 1e-10):
and the first command after mounting goes from 5.73s to 3.10s and from
2.50s to 1.26s. (On NTFS, both take under 0.3s.) "go mod verify" of all
75 modules of the build still passes over the mount.
Updates tailscale/corp#24037