Case Studies on JVQ.net

Case Studies on JVQ.net https://jvq.net/tags/case-studies/ Recent content in Case Studies on JVQ.net Hugo en-us Sat, 31 Oct 2026 00:00:00 +0000 jvq Replays 26 of Its Own CI Runs and Blocks a Windows Test Bug Four Pushes in a Row https://jvq.net/jvq-replays-26-of-its-own-ci-runs-and-blocks-a-windows-test-bug-four-pushes-in-a-row/ Sat, 31 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-replays-26-of-its-own-ci-runs-and-blocks-a-windows-test-bug-four-pushes-in-a-row/ <p>The fastest way to find out what a flaky test gate does with real failures is to give it some. jvq has its own CI history on GitHub: 26 pushes to main between October 18 and October 31, 2026, each tested on Linux, macOS and Windows, with a second run under the race detector on Linux. Eight of those 26 runs went red.</p> <p>So we fed that history to <code>jvq flaky</code> 0.7.0, run by run, in the order it happened, with each run’s real commit. One history per platform and test step, as the reference asks. A test that fails on Windows and passes on Linux has a Windows problem, and mixing the two would hide it.</p> A Crashed Writer Left Three Broken Lines in a 1 GiB Log and jq Stopped at the First https://jvq.net/a-crashed-writer-left-three-broken-lines-in-a-1-gib-log-and-jq-stopped-at-the-first/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/a-crashed-writer-left-three-broken-lines-in-a-1-gib-log-and-jq-stopped-at-the-first/ <p>Logs written by real services aren’t always valid JSON Lines. A process killed mid-write leaves half a line. The restarted process appends its first event straight after it, on the same line. Disk-full conditions, log shippers that split long lines and two writers sharing one file all do something similar. The file is 99.9999% fine and has a few lines that no parser will accept.</p> <p>jq treats the input as one stream of JSON, so the first bad line ends the run. This worked example shows what that looks like and what jvqq does instead. We took 1 GiB of generated logs, 3,073,492 lines, and cut three lines in half, each followed by the next line on the same line, the way a crashed writer leaves them. In the broken file they’re lines 812,345, 1,604,990 and 2,949,998. The commands below ran with jq 1.7.1 and jvqq 0.1.0 on a two-core cloud VM.</p> How jvqq Traced a 12-Minute Payments Outage Through 3 Million Log Lines https://jvq.net/how-jvqq-traced-a-12-minute-payments-outage-through-3-million-log-lines/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/how-jvqq-traced-a-12-minute-payments-outage-through-3-million-log-lines/ <p>The alert says checkout is slow. You have the last six hours of application logs as one JSON Lines file, 1 GiB and 3,073,492 lines, and a handful of questions to answer before anyone can fix anything. Which service? Since when? Which endpoint? Each question is a jq filter, and with jq the first one alone took half a minute.</p> <p>This is a worked example. The log is generated by jvqq’s benchmark generator, and we planted an incident in it: from 03:10 to 03:22, about 60% of the billing service’s payment requests fail with 503 after 2 to 4 seconds. Everything else in the file is ordinary traffic, with its usual background of errors. The commands and output below are real, run with jvqq 0.1.0 and jq 1.7.1 on a two-core cloud VM.</p> jvq Blocks a Go Logging Change That Added Two Allocations to Every Request https://jvq.net/jvq-blocks-a-go-logging-change-that-added-two-allocations-to-every-request/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-blocks-a-go-logging-change-that-added-two-allocations-to-every-request/ <p>An access logger writes one JSON line per request. In Go, the usual way to make that cheap is to append into a buffer the caller owns: no <code>fmt</code>, no <code>encoding/json</code>, no strings built along the way. Done right, the benchmark says 0 allocs/op, and the garbage collector never hears about the logger at all.</p> <p>That property is easy to lose and hard to notice. Time per call wanders by several percent from run to run on a CI machine. An allocation count doesn’t wander. That’s why jvq compares allocations exactly, and why their budget can be an amount, here 0, instead of a percentage. This worked example is a small Go package set up to show it, with two real commits run through jvq 0.5.0 on a two-core cloud VM.</p> jvq Catches a Python Cleanup That Made URL Parsing Nearly Five Times Slower https://jvq.net/jvq-catches-a-python-cleanup-that-made-url-parsing-nearly-five-times-slower/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-catches-a-python-cleanup-that-made-url-parsing-nearly-five-times-slower/ <p>A log pipeline pulls query parameters out of request paths, millions of times a day. The function that does it is eight lines of hand-written splitting. It’s fast, and it has a bug everyone has learned to live with: <code>%20</code> and <code>+</code> come through undecoded.</p> <p>So someone opens a pull request that fixes it the proper way, with the standard library. Two lines replace eight. The review is easy to approve. This is a worked example we set up to show what jvq does with a change like that: a small repository with a pytest-benchmark suite, four real commits, and jvq 0.5.0 run on each one on a two-core cloud VM.</p> jvq Flags an Update Check That Made a Go Command-Line Tool Nearly Four Times Bigger https://jvq.net/jvq-flags-an-update-check-that-made-a-go-command-line-tool-nearly-four-times-bigger/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvq-flags-an-update-check-that-made-a-go-command-line-tool-nearly-four-times-bigger/ <p>Some tools are judged by their size. A small binary that gets copied onto every build agent, baked into container images, or downloaded at the start of each CI job pays for every megabyte many times a day. Nobody looks at the size in review, because the diff doesn’t show it.</p> <p>jvq can gate the size of files your build makes, next to the timings. This worked example is a small Go command-line tool, <code>lvl</code>, that counts log levels in JSON Lines files. Two real commits were run through jvq 0.5.0 on a two-core cloud VM.</p> jvqq Reads a Week of Gzipped Logs Faster Than zcat Can Unzip Them https://jvq.net/jvqq-reads-a-week-of-gzipped-logs-faster-than-zcat-can-unzip-them/ Mon, 19 Oct 2026 00:00:00 +0000 https://jvq.net/jvqq-reads-a-week-of-gzipped-logs-faster-than-zcat-can-unzip-them/ <p>Most log files older than a day are compressed. Logrotate gzips them, object storage keeps them as <code>.gz</code>, and the habit for querying them is a pipe: <code>zcat app-*.jsonl.gz | jq ...</code>. It works, and it’s slow twice over. gzip unpacks on one core, and jq parses on one core, each waiting on the other.</p> <p>jvqq reads gzip and zstd files directly, recognized by their first bytes, and parses on every core. This worked example is a week of rotated application logs: seven daily files from jvqq’s benchmark generator, 150 MiB each uncompressed and about 23 MB each compressed, 161 MB in all and 3,151,367 lines. The commands below ran with jvqq 0.1.0 and jq 1.7.1 on a two-core cloud VM, with the files already in the page cache.</p>