BitSpeed Inspect Case Study Traces a 180 ms Slowdown to First Byte Wait

Tue, 20 Oct 2026 00:00:00 +0000

Here’s the situation. A request feels slow. Someone changes something, and it feels faster. Was it the connection, the server’s first response, or reading the body? A single total won’t tell you, and a second total won’t either.

This case uses the saved recordings in the BitSpeed repository’s examples folder. They were made with the released Inspect binary against a local test server on loopback. The “before” server held its response headers for 200 ms. The “after” server held them for 20 ms. Everything else stayed the same: same URL path, same request settings, three fresh-connection samples each.

BitSpeed Transfer Case Study Resumes a Killed 256 MiB Upload

Tue, 20 Oct 2026 00:00:00 +0000

The test is blunt. Start a file transfer, kill both ends with SIGKILL partway through, start them again and see what happens. No clean shutdown, no chance to save state on the way out. If the tool’s bookkeeping is honest, the restart should know exactly which pieces arrived and send only the rest.

This run used the released Linux amd64 build of Transfer 0.1.0, downloaded from the release and checked against its SHA256SUMS. The file was 256 MiB of random data called video.mov, split into 256 chunks of 1 MiB. Sender and receiver ran on the same machine over loopback.

Case Studies on BitSpeed.org

BitSpeed Inspect Case Study Traces a 180 ms Slowdown to First Byte Wait

BitSpeed Transfer Case Study Resumes a Killed 256 MiB Upload