Daniel Balcarek's article API Performance Testing: How to Design Realistic Tests makes a straightforward point: load should reflect how people use the system, and the target load should come from an explicit requirement or telemetry. It made me ask a more useful question about my existing suite: What does its load actually represent?
My suite already measured percentiles, throughput, error rates, warm-up phases, and stepped load. It could detect technical regressions and compare individual endpoints under repeatable conditions. What it could not yet explain was which real usage pattern those requests represented.
I extended it with roles, sessions, think time, read and write journeys, and explicit cleanup rules. Before I obtained performance numbers worth discussing, the new journeys exposed authentication, API-contract, cleanup, and rate-limit problems. That is the central result: a journey must be valid before its latency can mean anything.
What the existing suite already
Discussion
Begin the discussion
Begin something meaningful by sharing your ideas.