I built a small tool with esp32-review — code is open, feedback welcome
Most esp32-review articles stop at "how to use it" and never cover "when not to use it". This is an attempt at the second half.
On trade-offs, my view is this: if nobody on the team owns this area long-term, do not introduce a second mechanism. With two coexistence you first have to work out which one is even in play when things break, and that costs far more than the performance you saved.
// Minimal reproduction: you must use a real long-tail distribution here.
// Uniform load-test traffic will never trigger this.
func (s *Server) handle(ctx context.Context) error {
conn, err := s.pool.Acquire(ctx)
if err != nil {
return fmt.Errorf("acquire: %w", err)
}
defer conn.Release()
return s.do(ctx, conn)
}What genuinely surprised me was the tail. The average looked great while P99 jumped by an order of magnitude past some threshold. The cause was not esp32-review itself but our upstream connection reuse — the load test traffic was too clean and hid the long-tail requests.
Worth noting: the official docs do cover this, just in a very inconspicuous spot. I only found it reading the source comments, where the author explains the reasoning — roughly "so that it degrades into predictable behaviour in extreme cases".