[mrueg]

The configuration file is consulted on every http request so that changes are picked up without a restart. That read is an os.ReadFile plus a strict YAML unmarshal plus header validation, every time — on the scrape path, and on every TLS handshake through GetConfigForClient.

It is by far the most expensive part of serving a request. Measured against the handler it wraps: the toolkit's handler cost 15.9µs/request where the wrapped handler cost 0.87µs.

Change

Keep the parsed configuration and reuse it while the file's modification time and size are both unchanged, replacing a read and a parse with a stat in the common case.

BenchmarkGetConfig   14743 ns/op   7515 B/op   64 allocs/op   # before
BenchmarkGetConfig    1160 ns/op    515 B/op    3 allocs/op   # after

The tradeoff, stated plainly

An edit is still picked up on the next request, and the existing TestConfigReloading continues to cover that. The limitation worth being explicit about is that a write leaving both the modification time and the size identical is not noticed. On a filesystem whose timestamps have sub-second resolution that needs a rewrite within the same nanosecond at exactly the same length; where timestamps have one-second resolution the window is a second.

I have added a test that pins this behaviour so it is documented rather than discovered later. If you would rather not accept that window at all, this one is easy to drop — the other PRs in this batch do not depend on it.

Details

• Failures are not cached, so a file that does not parse is reported on every request until fixed, not once.
• Callers get a copy of the Config struct, so one caller cannot change what the next sees. The maps inside are shared and only ever read.
• Certificates are still loaded from disk on every handshake. Caching those is a separate change and deliberately not part of this one.

🤖 Generated with Claude Code

[ArthurSens]

Generally looks like a good idea :)

One question, what happens with stale cache entries? Do they remain stored in memory forever?

I'm also wondering if we could continue to read file on every request and store []bytes from the parsed file, but only parse the file again if bytes.Equal is false. Would that be just as efficient as the current PR?

[ArthurSens]

This change seems irrelevant to the end-user, we can keep that out.

[roidelapluie]

Are we really speaking about adding such complexity for 15.9µs/request ? OS caches the file read, it should not be a great deal.