D5What it costs the developer
Every tool needs a day before it tells you anything.
Load tests, profiling, tracing, query analysis. So they all wait for a quiet week, and the quiet week does not come.
What actually goes wrong
Profiling a Go service is well supported and still a project: wire pprof, get a load generator, produce realistic traffic, read a flame graph, correlate it with the queries that ran.
Because the setup costs a day, it is done after the complaint rather than before it, which is the most expensive possible order.
What Grit does about it
- Request tracing, the queries each request ran, runtime metrics and errors with their request attached are mounted at /pulse in every project.
- The slow query list is sorted by total time rather than worst case, which is what finds the cheap query run ten thousand times.
- Allocation budgets ship as tests, so a change that allocates more on the hot path fails a build rather than being noticed in a year.
The commands
Already running
grit start# http://localhost:8080/pulse
The budgets, as ordinary tests
cd apps/api && go test ./internal/handlers/ -run TestAllocationBudgets
What it does not do
Pulse explains load; it does not generate it. A load generator belongs out of process, which is why the docs point at k6 rather than shipping one in the API.