A metric turns a performance claim into evidence. Replace “the system is much faster” with measurements that show how much, under which conditions, and compared with what. section 8.5.4 section 14.3.1
Use metrics to make technical decisions and explanations concrete:
- Measure latency when responsiveness and spikes matter. section 9.3.3
- Measure throughput, bandwidth, I/O operations, resource use, or price-performance when comparing systems. section 14.3.1
- Show metrics with tables, charts, screenshots, or flame graphs rather than relying on vague adjectives. section 8.5.4
- Explain the tradeoff behind an improvement: higher performance may cost developer experience, usability, or implementation effort. section 2.2.7
A credible performance comparison
A benchmark comparing Graviton2 and x86 database instances specifies processors, cores, memory, storage, network, prices, test phases, I/O operations, and throughput. It reports a 15%–25% price-performance improvement and provides charts and tables, making the result easier to reproduce and trust. section 14.3.1
Treat metrics as clues, not decoration. State the baseline, test setup, measured dimensions, and practical consequence; then show what changed and what the improvement costs. section 8.5.4 section 9.3.3
