Testing

We’re going to chase down one benchmark result that looks suspiciously good. The function under test calls make([]byte, 64) every time it runs, and the benchmark reports 0.34 ns/op, 0 B/op, 0 allocs/op. That is almost three billion heap allocations per second on a laptop, and the allocator counted none of them. (It comes from a real run, more on that below.) Keep it in your pocket; we’ll follow it the whole way. ...

We’re going to write one small benchmark, run it, and read every word of what comes back. By the end you’ll know where ns/op comes from, what -count and -benchtime change, what the -16 is, and how to ask the compiler and the profiler what the benchmark really did. Here is the line we’ll be decoding: 1 BenchmarkMakeBuffer-16 99632604 18.53 ns/op 64 B/op 1 allocs/op This is a primer before part 1 of Why Your Go Benchmarks Are Lying, the written companion to my GopherCon UK talk, Why Your Go Benchmarks Are Lying. The series argues about numbers like the one above, so it helps to know how they are made first. If you have run go test -bench before, skim. ...

Observability is the key to understand how your application runs and behaves in action. This is especially vital for distributed environments like Kubernetes, where users run Cloud-Native microservices often written in Go. Among many other observability signals like logs and traces, the metrics signal has a substantial role. Sampled measurements observed throughout the system are crucial for monitoring the health of the applications and, they enable real-time, actionable alerting. While there are many open-source robust libraries, in various languages, that allow us to easily instrument services for backends like Prometheus, there are still numerous possibilities to make a mistake or misuse those libraries. ...