AI-Driven Website Load Testing: a step-by-step guide for QA engineers using Claude and PFLB’s MCP server

The task: Black Friday is coming

Here is the situation, and it may sound familiar. An online store. Black Friday a few weeks away. Marketing has run its forecast and put a number on the table: 1,200 shoppers on the site at the same time at the peak. Someone in the standup asks the obvious question. Will the site hold?

Nobody knows. And the team that is expected to find out is a manual QA team. What they have is what most QA teams have: four functional test cases in a tracker — browse the catalogue, search, check out as a guest, sign in and check out — and access to a staging environment. What they do not have is any of the things load testing traditionally requires. No JMeter skills. No load generators. No performance engineer.

Until recently, this is where the story would stall. Load testing has a reputation as a specialist discipline, and the reputation is earned: the scripting alone takes months to learn. This article is about doing it anyway, with three tools that fit a QA team's reality. The AI coding assistant Claude, connected to jmx-mcp, PFLB's MCP server: it runs from a single docker compose up on a laptop and is published, free to run, and source-available. The PFLB platform, which supplies cloud load generators on AWS, billed per VUser-hour, so there is nothing to own. And Datadog's free tier for watching the server itself.

The whole exercise, from the first prompt to a reviewed report in the development team's hands, took one working day.

The requirements: what “ready” means in numbers

“Will the site hold?” is not a testable question. Hold what, for how long, and how slow is too slow? Before any load is generated, the team has to turn the marketing forecast into numbers a test can pass or fail. Performance engineers call these non-functional requirements. You can think of them as acceptance criteria for speed.

The honest way to set them is to start from how the site behaves when it is comfortable, and demand that it not degrade too far from that under load. So the first measurement is a gentle one: 100 users for 20 minutes, ramping up over 2 minutes. That run produced 7,605 requests with zero errors, and this picture of the store on a calm day:

A fair question at this point: measured with what? We have not built anything yet. The honest answer is that this baseline is the smallest of the three test plans the assistant builds later in this article. We show its numbers early, out of chronological order, so that the requirements and the baseline they came from read as one piece.

The chart uses a term worth pausing on: p95. A p95 of 904 milliseconds means 95% of requests finished within 0.9 seconds, and the slowest 5% took longer. Why track the slowest 5% instead of the average? Because the slowest 5% are exactly the shoppers who give up and abandon their carts. Averages actively mislead under load: later in this test, at 1,200 users, the average page still took a pleasant 0.33 seconds while the p95 had already tripled. The average said all was well. The slowest shoppers disagreed.

From the baseline, the requirements almost write themselves: allow roughly 1.5× degradation from comfortable, round to numbers a human can remember, and add a few absolute guards. Here is what the team signed off:

• 1,200 concurrent users held for at least 20 minutes.
• Pages — home, catalogue, search, cart — p95 ≤ 1.5 s (baseline 0.6–0.95 s).
• Checkout steps — address, shipping, and so on — p95 ≤ 2 s (baseline 0.4–1.05 s).
• Placing the order: p95 ≤ 3.5 s (baseline 1.3–2.1 s).
• Errors, HTTP and application: ≤ 1% (baseline: zero).
• Server CPU in steady state ≤ 85% (baseline ≈ 38% busy).
• After an overload spike: back to baseline behavior within 10 minutes.

That CPU line raises a practical question: how will we see the server's CPU at all, if all we have is staging access? This is where Datadog's free tier comes in. Its agent goes on the host, and the free plan covers 5 hosts with one day of retention, enough for a test day. No Datadog? The platform ships its own downloadable monitoring agent, and anything that can export a plain timestamp-and-value CSV works too, as the analysis section will show.

The method: three plans and a staircase

With the requirements written, the team hands the problem to the assistant. Not a specification — a goal. The exact prompt appears in the next section, and it says, in essence: here is our store's URL, here are our test cases and test data, marketing expects 1,200 shoppers at once, find out whether we survive. What comes back is a method. The assistant proposes three test plans: the small baseline you have already seen, a short rehearsal, and the main event, a 95-minute staircase. The team's job is not to design any of this, but to check that the plan makes business sense.

The first thing to check is who those 1,200 users are. Sending 1,200 shoppers straight to checkout would be nonsense; on a real Black Friday most visitors just browse. The shape of the crowd comes from the store's own web analytics for an ordinary day: 55% of sessions browse the catalogue, 16% search, 16% sign in and buy, 13% buy as guests. Applied to the forecast, the model looks like this:

The second column of that table is why the four functional test cases matter so much: each business process in the model is one of the recorded flows, in exactly these proportions.

The next honesty check is pacing. Real shoppers do not click continuously. The same analytics show an average session of about 7 minutes across about 10 pages — roughly 40 seconds per page. So each virtual shopper in the plan pauses 25 to 60 seconds between clicks, which testers call think time. This matters more than it looks: the same 1,200 users with 1-second pauses would be a dishonestly harsh test of a load that will never occur, and a different test altogether.

Then there is the load shape itself: one 95-minute run in four acts. Ramp up over 5 minutes to 600 users and hold for 20 minutes. Climb to 1,200 and hold for 20. Climb again to 2,200 and hold for 20. Then drop back to 600 for a final 20.

Why 600 first? Because it is half the forecast, and it is supposed to be easy. If the store struggles at half the expected crowd, the test has already produced its headline and nobody needs to wait an hour for it. The 1,200 plateau is the requirement itself. The 2,200 plateau asks the uncomfortable question every forecast deserves: what if marketing under-forecast by 80%? And the return to 600 tests something teams forget to test: whether the site recovers from an overload by itself, or stays wedged until someone restarts it. Each plateau is deliberately flat, because steady sections are the only parts of a load test you can read trustworthy numbers from.

And the rehearsal? It is a ten-minute miniature of the staircase, and its only job is to prove that the phases start and stop on schedule before real generator hours are spent on the full run. Cheap insurance before the full run.

Building the test from your test cases

Now the part that used to be the barrier: turning four functional test cases into a working load test. Here is the entire human contribution to that step. The MCP server is already running on a laptop; the assistant is connected to it; the prompt states the goal and nothing else.

$ claude mcp add --transport http jmx-mcp http://localhost:8090/mcp $ claude "We need to know whether our store at https://bench.pflb.us survives Black Friday: marketing expects 1,200 shoppers on the site at once. Here is the file with our test cases (test-cases.csv) and our test data files (test-data/). Plan and build whatever load tests answer that question — and be gentle with the site along the way." ● assistant: Here is how I would answer it with three JMeter plans built from the same recorded flows: a 20-minute baseline at 100 users to measure "normal", a 95-minute staircase 600 → 1,200 → 2,200 → 600 to test the requirement, the headroom above it and the recovery after it, and a small rehearsal copy to verify the schedule cheaply first. Starting now — walking your test cases in a browser.

Notice what the prompt does not contain: no thread groups, no ramp-up schedules, no plan structure. The three plans are the assistant's answer, not the team's instruction.

The test cases themselves live where yours do: in a tracker, Jira in this team's case. Getting them out is a standard CSV export, one file. This is what the assistant received:

Alongside the cases, the team prepared three small data files, the same kind of fixtures a QA team makes for any test cycle. users.csv holds 20 test accounts, email and password, created on staging by QA the normal way. search-terms.csv holds 10 phrases real customers type. products.csv holds 16 product-page URLs so the load spreads across the catalogue. Why 20 accounts rather than one? Because each virtual shopper must sign in as a different user; a thousand shoppers on one account would let the site serve everything from cache, and you would be testing the cache, not the store. The assistant wires these files into the plans so that each virtual shopper draws its own row. All three are downloadable in the Artifacts block at the end of this article.

Then the assistant goes to work, and this is where the years-to-learn part happens without the team. It walks all four test cases against the live store with a real browser and records what actually crosses the wire: 47 requests in total. Forty-seven, for four short cases? Yes, because one “page” is never one request. Opening a category page also fetches the menus, the product tiles, the mini-cart. A load test that skipped those would be testing a store nobody visits.

The hardest part of the recording is invisible in the result, so it deserves a paragraph. Modern sites stamp every session and every form with security tokens: one-time values the server generates and expects back. Replay a recorded token and the server rejects you. A working plan must extract a fresh token on every pass and substitute it into the next request. This is called correlation, and it is the classic skill barrier of load testing. The assistant handled it, including one genuinely obscure PrestaShop subtlety: the checkout token is regenerated after the personal-information step, so the extractor has to sit after that step, not before it.

● recorded all four flows against the live store — 47 requests in all (one "page" is many requests: menus, product tiles, the mini-cart), every dynamic value identified ● session cookies and per-form security tokens correlated: the plan extracts a fresh token on every pass instead of replaying the recorded one — including the PrestaShop subtlety where the checkout token is regenerated after the personal-information step ● test data wired in: sign-in accounts, search terms and product URLs now come from your CSV files, so no two virtual shoppers collide

Recorded is not the same as trusted. Before any real load, the assistant validates the plans against the live store in a short ladder, each rung slightly heavier. “Users per flow” here means per recorded flow: at the top rung, 8 users on each of the four flows, 32 virtual shoppers in all.

● validate_jmx (1 user/flow, 60 s) → 114 samples, 0 failed ● validate_jmx (3 users/flow, 90 s) → 413 samples, 0 failed ● validate_jmx (8 users/flow, 120 s) → 1,362 samples, 0 failed ● every extractor anchored to live tokens, not recorded literals; 6 CSV data files wired in and rotating

Three rungs, 1,889 requests, zero failures. A fact worth saying plainly: through all of this, nobody on the team opened a JMX file. One more property matters later: all three plans are generated from the same recorded flows, so their numbers are comparable by construction.

The test itself: 95 minutes, four acts

A laptop cannot pretend to be 2,200 people; that is what the platform's cloud generators are for. After the ten-minute rehearsal confirmed the schedule behaves, one more request to the assistant sends the real thing up.

$ claude "The staircase plan is validated. Upload it to the PFLB platform with its data files and start the run." ● assistant: Uploaded — the platform created the test and returned its page: platform.pflb.us/account/tests/… Starting the run now. ● run accepted: 2,200 virtual users at peak, AWS cloud generator ● 13:32 UTC — load begins; watch it live on the run page ● 15:07 UTC — the platform stops the run right on schedule: 95 min sharp

The platform creates the test, returns a link to its run page, and from 13:32 UTC the team is simply watching live charts: a blue staircase of users climbing exactly as planned, green bars of requests, response-time lines that will soon get interesting. At 15:07 UTC the platform stops the run on its own, 95 minutes sharp. Nobody babysits a timer.

Act one, 600 users. Quiet. Response times sit at their baseline values, errors are zero, host CPU idles around 47%. Half of Black Friday costs this store almost nothing.

Act two, 1,200 users. The requirement itself. Errors stay excellent at 0.11%, and if error rate were the only gauge, you would call it a pass and go home. But the response times lift. Pages touch 1.5 seconds, right at their limit. Placing an order stretches to 3.7 to 5.0 seconds against a 3.5-second target. Host CPU reaches 83%. The site is not failing; it is queueing. Every request now waits in line for a nearly saturated CPU, and the wait is the slowdown.

Act three, 2,200 users. The queue becomes a collapse. A third of all requests — 32.6% — come back as HTTP 500 errors, and p95 response times pass 20 seconds. On the server, the load average hits 158. Load average is the length of the queue of processes waiting for CPU time; a healthy number is about one per core, which on this 8-core host means 8. At 158, a request spends most of its life not being processed, just waiting for its turn. One vivid detail says it best: our own monitoring probe on that host could no longer complete its database queries during the collapse. The watcher was queueing behind the watched.

Act four, back to 600. The most quietly reassuring twenty minutes of the day. Within about 10 seconds of the load dropping, the errors stop. Within about 3 minutes, response times are fully back to baseline. No restarts, no stuck processes, nothing wedged. Of all seven requirements, recovery is the one this store passes most convincingly.

The results, phase by phase

Charts tell the story; the steady-state numbers make it precise. Each column below is one 20-minute plateau of the same run, measured the same way, from the same recorded flows.

Read the 1,200 column top to bottom and the pattern is unmistakable. At exactly the forecast load, the store serves pages on the limit and takes orders over it. The money moment, placing the order, is the slowest operation on the site and the first to break, because checkout does the most work per click.

Notice also what the 1,200 column does not show: errors. At 0.11%, every smoke check, every uptime monitor, every quick manual click through the site would report green. This is a quiet failure. On the real Black Friday it would not surface as an incident; it would surface three weeks later as a chart of abandoned carts.

The 2,200 column shows something different in kind, not just in degree: a hard throughput ceiling. Through that plateau the store sustained roughly 85 successful requests per second, and no more. Past the ceiling, extra demand does not slow things down further; it converts directly into errors, one for every three requests.

Finding the bottleneck: the AI report

The test is done, and here the exercise changes audience. Everything so far lived in a chat with an assistant and a run page the QA team watched. But the people who must now act on the findings, the development team, were not in that chat and should not have to be. They need a document: findings, evidence, recommendations, behind a link anyone can open. Not a war story retold at standup. This is what the platform's AI report is for.

The server-side picture goes in first. During the run, Datadog's agent had been collecting host CPU, load average, memory, per-container CPU for the PHP tier and MySQL, and MySQL internals: running threads, row-lock waits, connections, slow queries. After the run, the assistant exported ten of those series from the Datadog API into plain timestamp-and-value CSV files, and the team attached them on the test run page — System metrics, Add, a short form per file. Ten files, a few minutes. This is also why teams without Datadog are not stuck: any monitoring that can produce a timestamp-and-value CSV plugs into the same slot.

Then one click, and about three and a half minutes later, the report exists.

Its findings, in brief. The last stable level was 1,200 users; at 2,200 the failure is catastrophic, with p95 around 35 seconds and 32.6% errors, against a hard ceiling of about 85 successful requests per second. The resources tell the why: host CPU at 99.9%; the PHP application container pinned at its 450% ceiling, meaning 4.5 of the 8 cores; the MySQL container at 280% CPU and about 1.1 GB of RAM. And one crucial negative finding: the database itself never queued. Running threads peaked at 11 and row-lock waits stayed at zero throughout.

The most interesting page is the correlation study across the ten imported series. The place-order response time tracks host CPU with a correlation of 0.73, and tracks load average at 0.95. How do you read that? A correlation of 1.0 would mean two curves move perfectly in step. At 0.95, when the CPU queue grows, checkout slows, almost beat for beat. The report's own wording: host queue depth is the primary driver of payment latency.

All of which condenses to one sentence: the bottleneck is CPU capacity of the PHP application tier; every page is computed from scratch, and checkout, the heaviest flow, suffers first.

The report's second key property, after shareability, is that it is editable, and it earned its keep the same day. The AI wrote the analysis in 3.5 minutes; the QA engineer then reviewed it against the data, the way you would review a strong analyst's draft. Two of its interpretations did not survive the check. It read the planned final ramp-down as an outage, and it floated a database row-locking hypothesis even though the imported lock-wait series is flat zero. Both were corrected directly in the report editor, in minutes, and the reviewed version is what development received. The public guest link you can open right now is that reviewed version. Generate, review, share: the review step is not a workaround, it is the workflow.

The verdict, and what happens next

So, does the store survive Black Friday? No. And the reason is worth stating carefully, because it is not the reason a smoke test would find. The store does not crash at the forecast load. It fails the requirement that matters most: at exactly 1,200 users, paying slows to 3.7 to 5.0 seconds against the 3.5-second target, with the CPU at 83% and no headroom left. And if the forecast is under by 80%, one in every three clicks becomes an error.

Because the diagnosis is specific, the fix list is specific, in order of leverage. First, more CPU for the PHP tier: more cores, or a second application container. Second, cache the pages that are recomputed identically for every visitor; the correlation evidence says computation, not data, is what the store runs out of. The report adds a third, smaller item: MySQL buffer-pool tuning. Then re-run the same test and watch the same rows of the same table. This is why comparable plans matter: “place order p95 at 1,200 users” is a number that either improves or does not. Specific beats “optimize performance” every time. And if nobody on the team has the bandwidth for the re-run, this is exactly the work PFLB’s performance testing service does for clients.

Everything used in this article — the test plans, the test cases, the data files, the metric exports — is in the Artifacts block just below, so you can retrace any step.

The store was never the point. The point is what a manual QA team was able to answer in one working day, with evidence: what survives, where it breaks, why it breaks, what to fix first, and whether it recovers on its own. The parts of load testing that used to take years to learn — building a correlated script, running a correlation analysis across ten metric series — were done by AI. The parts that remained human are the parts QA teams are already good at: deciding what “ready” means, and checking an analysis against the data before signing it.

Your staging site, your four test cases, a forecast someone in marketing already has. Why not this week?

Artifacts

Everything the article claims is checkable. The runs were recorded on August 18, 2026, the AI report on August 19; software: jmx-mcp at the commit current with this article, Apache JMeter 5.6.3, PrestaShop 8, Datadog Agent 7.

Download what we used: loadtest.jmx — the 95-minute staircase plan the assistant built; baseline.jmx — the 100-user baseline plan; test-cases.zip — the four test cases, cards and CSV export; test-data.zip — users.csv, search-terms.csv, products.csv and friends; datadog-metrics.zip — the ten metric CSVs imported into the run; transcript-plan-building.jsonl — the full assistant session that built the plans.

Choosing a tool for this workflow: our comparison of 18 load testing tools for 2026 rates every vendor on the same AI action scale, A0 to A3.

• The AI report on the staircase run — public guest link · https://platform.pflb.us/shared/reports/68d6326e-27c0-48b9-a30e-23df0348b007 · PFLB Platform, generated August 19, 2026
• jmx-mcp — the MCP server used in this article · built by PFLB; the repository opens with the public release
• The test store · https://bench.pflb.us/ · a stock PrestaShop 8 on a single 8-core host — see the staging disclosure above
• Datadog free tier — infrastructure monitoring · https://www.datadoghq.com/pricing/ · up to 5 hosts, 1-day retention; enough for a test day
• Little’s law — how user counts come from analytics · https://en.wikipedia.org/wiki/Little%27s_law · the one formula in this article
• Apache JMeter · https://jmeter.apache.org/ · the engine underneath: stock thread groups only, no plugins