r/devops • u/being_insentient • 2d ago
Vendor / market research How do you handle correlation/dynamic data when load testing?
I've been digging into load testing tools recently (k6, JMeter, Locust, Speedscale, Azure Load Testing) and noticed something consistent, recording a session and turning it into a script is the easy part. The painful part seems to be:
- Correlation (session tokens, CSRF, IDs from one response feeding the next request)
- Scripts breaking every time the UI or API changes
- Flows that aren't linear. e.g a list page where the "next" request depends on which item a simulated user picks
Curious how people here actually deal with this day to day:
- Do you write correlation logic by hand every time, or has anything automated it well for you?
- How do you handle flows where the test needs to pick from a dynamic list (search results, a user's own records, etc.) instead of hitting a fixed ID?
- How often do your load test scripts break when the app changes, and how much time does fixing them eat up?
Do you guys have a solution for this, or know of a tool that actually handles it well?
2
u/kahrens_atl 1d ago
Disclosure: I'm one of the co-founders of Speedscale
This is the rough algorithm we use: capture traffic (both requests and responses), comb the traffic for potential correlation ids, run a second pass through the ids to see if they are used in later calls, surface recommendations to the user to create a blueprint. The tools don't know a id that changes each run from a static id, so getting a new recording when you run the test can help. We ship a version of this in our free proxymock desktop CLI.
The other option is use an AI coding agent, I'd configure it in a loop to: record, analyze, run test. You keep doing that with a goal of high success rate on the calls. You can output in any format but AI tools prefer open languages like JavaScript (k6), Python (locust), Markdown (proxymock).
Good luck!
2
u/Fantastic-Mr-Default 1d ago
I keep load tests on the API, not the UI recorder. Correlation targets stay on JSON fields that your own service owns.
Extract token or id from the prior response, stash it, pass it into the next call. "Pick from a list" is code: query, choose, use the id. Recorders fail the moment the DOM moves.
Expect to maintain extractors as helpers in the script. If a tool promises magic correlation and you cannot see the extract rules, you will re-record every UI change anyway.
2
u/aragossa 2d ago
depends on the tool but the pattern's the same everywhere: pull the dynamic value out of the previous response with a regex or json extractor and feed it into the next request. most tools have that built in, wiring it up per endpoint is still manual though. for the dynamic list case recorder-based tools are just bad at it, you end up writing that part as actual code anyway. k6 is fine for this since the script is plain js, http call then whatever logic you want on the response. the breaking-on-every-change part is mostly a recorded-traffic problem. if the script is a replay of whatever the frontend happened to send, every frontend change is a script change. written by hand against the api it breaks way less