Throughput vs Latency: How to Present Results Stakeholders Actually Understand

Executives ask "how many requests per second?" while engineers guard p99—then both leave confused when RPS rises and UX worsens. Throughput and latency tell different stories; conflating them erodes trust in perf programs and leads to bad capacity bets.

Little's Law intuition: in steady state, average concurrency ≈ arrival rate × average response time. Higher RPS with fixed capacity often means longer queues—show both throughput and percentiles on the same slide with the same test duration and env footnote.

This guide maps metrics to audiences, gives a k6 tagging pattern for checkout-focused exports, and includes a decision table for the questions stakeholders actually ask in readouts.

What to chart for whom

Different audiences need different cuts of the same k6 run—never one chart forced on everyone:

• Leadership: SLO pass/fail at stated RPS, p95/p99 vs target, trend vs last release, one-line env fidelity caveat.
• Product: Journey-level latency (checkout, search submit)—not global service average hiding slow steps.
• Engineering: RPS achieved, errors by route tag, saturation signals from APM, failed checks.
• Finance/capacity: Max RPS meeting SLO with headroom %—not peak RPS alone.

Never present only http_req_duration avg—mean hides tail pain (p95 vs p99). Never present peak RPS without saying whether SLOs still passed at that rate.

The footnote that saves your credibility

Every stakeholder slide needs: RPS, duration, environment, synthetic data yes/no. Missing footnotes cause "staging said 2k RPS" legends in production postmortems (staging vs prod).

k6: export-friendly tags

Segment checkout (or your revenue path) for product slides; keep report:exec tag for filtering exports from the same run engineering uses.

Example (illustrative). Steady ARR with route-specific thresholds.

What this demonstrates:

• constant-arrival-rate fixes business RPS—leadership number matches test config.
• Thresholds on route:checkout only—product slide not polluted by health checks.
• Tag report:exec filters Performate PDF sections for leadership template.
• Think time included—RPS honest vs machine-gun requests (VU sanity).

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    steady: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.RPS || 50),
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 25,
      maxVUs: 100,
      tags: { report: 'exec' },
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<800', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get(`${BASE}/catalog`, { tags: { route: 'browse' } });
  sleep(1);
  const res = http.post(`${BASE}/checkout`, '{}', {
    headers: { 'Content-Type': 'application/json' },
    tags: { route: 'checkout', report: 'exec' },
  });
  check(res, { ok: (r) => r.status < 500 });
  sleep(0.5);
}

Patterns that work

• Two charts: throughput (RPS achieved) + percentiles at that RPS—same run, same footer.
• Before/after at same RPS for release comparisons—"faster" claims require controlled RPS.
• Link performance budgets when UI latency is part of journey SLO.
• Performate filter by route:checkout before PDF export—product readout in one click.

Anti-patterns to avoid

• Bragging peak RPS from stress test where errors exceeded SLO—throughput without quality is noise.
• Mixing load and spike runs on one trend line—shapes differ (stress vs load vs spike).
• Executive slide with only mean latency—tail users drive support tickets.
• Comparing this week's staging RPS to last month's production slide—env mismatch.

Pro tip (example command): percentile-focused summary for exec appendix.

k6 run stakeholder-run.js --summary-trend-stats="p(95),p(99),avg" --tag report=exec

What this command demonstrates: summary block pastes into appendix with both tail and mean—reviewers see you did not cherry-pick average only.

Decision table: stakeholder question vs answer

Lead with SLO percentiles at stated RPS—throughput is context, not the headline, unless the question is explicitly capacity headroom.

Observability and reporting checklist

• One page: RPS chosen, duration, env fidelity note, synthetic data confirmation.
• Separate charts for throughput achieved and percentiles—same run ID.
• Link to performance budgets when UI involved in journey.
• Archive export with release SHA—week-over-week comparison in Performate.
• Product route tagged (route:checkout)—not only global http_req_duration.
• Spike vs load labeled if multiple runs in deck—do not merge test types.

How Performate supports stakeholder reporting

Below is a concrete workflow example for exec-ready checkout reporting—adapt routes to your revenue path.

Example: one run, two exports

1. Run steady scenario at agreed RPS—5m minimum for stable percentiles. Problem solved: leadership number tied to real test config, not back-of-napkin.
2. Filter report by route:checkout and tag report:exec. Problem solved: product slide excludes unrelated routes from same run.
3. Export PDF with percentile trends + RPS footer auto-included. Problem solved: no manual spreadsheet transcription errors.
4. Duplicate slide template—RPS + p99 + pass/fail vs SLO doc. Problem solved: consistent readouts quarter over quarter.
5. Archive with release SHA beside engineering full export. Problem solved: audit trail when someone asks "which build was this?"
6. Present comparison view week over week at same RPS—not mixed shapes. Problem solved: "are we faster?" answered honestly.

That workflow maps directly to the cta in this post: simplify path from k6 run to stakeholder-ready evidence.

Closing takeaway

Stakeholder-ready perf reports lead with SLO percentiles at stated RPS, not throughput bragging rights. Fix the RPS footnote, split charts, and tag revenue routes before the next exec readout.

Take your last k6 export, add RPS and env to slide one, and move peak throughput to appendix where it belongs.

Try Performate free | Guides | Book a demo