Role-based journeys turned up a 429 before they produced a usable p95

The runner takes one credential pair per role, so the five regular-user sessions all sign in as the same regular user ^[9]. A sixth regular-user login came back 429, and the final low-load comparison was trimmed to a 5:3:1 mix of regular-user, agent and administrator sessions ^[7][6]. That leaves nine sessions running on three accounts ^[20]. The limiter counted six sign-ins on one identity ^[21].

Each virtual session owns one .NET HttpClient and cookie handler, reuses that client for the whole journey, and records request duration after the full response body has been read ^[10]. The author says that keeps the browser-style cookie flow close to the existing automation, and that client and network time are part of the measured latency ^[12]. Percentiles use the nearest-rank calculation ^[11]. So a p95 from this suite transfers to another setup only if the generator sits on a comparable network path and reads comparable response bodies, and only if the other side computes its percentiles the same way. Against a server-side histogram these figures include time the server never spent. The runner extends an existing PowerShell performance suite, and the author says it was not selected as a claim that PowerShell measures better than k6 or another load-testing tool ^[13].

A load test that checks roles can find functional bugs. Every session signs in separately, verifies the role the server returns, waits between actions, and starts during a ramp-up period rather than at the same instant ^[8]. Think time here means deliberately waiting between actions instead of firing requests as fast as the client can ^[19]. A journey that asserts who it is and what it may see fails on a broken contract before it reports any number. The earlier version of the suite answered how defined endpoints behave under controlled, repeatable load. The question it left open was how people actually use the system ^[18].

I would copy the order of operations. The author proves a journey is functionally and technically valid, checks that it stays stable when sessions run in parallel, interprets latency, throughput and error rate only after that, and reaches for system and resource metrics when investigating causes ^[15]. The author's central result is that a journey must be valid before its latency can mean anything ^[4].

The author describes the implemented slice as narrow: it adds a reviewable journey model, with no telemetry-derived workload target and no continuous resource correlation across every relevant system layer ^[16]. Daniel Balcarek's article, the piece that prompted the rewrite, argues that load should reflect how people use the system and that the target load should come from an explicit requirement or telemetry ^[17]. The suite's own documentation is clear that the mix describes sessions, not people, and is not a simulation of nine independent identities ^[9].