Performance Testing Interview Questions

"They all put load on the system, but each one answers a different question. A load test runs the traffic we expect at peak, like the busiest hour, and checks we meet the response time and error targets. A stress test keeps adding load past that point until something gives, so we learn where the limit is, what fails first, and whether the system recovers cleanly when the load drops. A spike test throws a sudden burst at it, like a sale opening or a push notification going out, to see if autoscaling and queues cope. A soak test holds normal load for many hours, sometimes overnight, to catch memory leaks, growing queues or connection pools that slowly run dry. Before a big launch I'd usually run the load test first, then stress and spike, and a soak before the release goes out."

"A slow climb over hours is the classic soak finding, so first I'd line up the response time graph with server metrics over the same window. On a JVM or a similar runtime, I'd look at memory after each garbage collection. Normal is a sawtooth that drops back to a steady floor; if that floor keeps rising, something is holding on to objects, and a heap dump will show what. Next I'd check pools: database connections, worker threads, open file handles. If something takes one and doesn't give it back, requests start queueing. Then I'd look at data that grows with the run, like a table the test keeps inserting into with no index, a cache with no eviction, or logs filling the disk. The resource that grows in step with the slowdown is usually the answer, and I'd give developers that evidence, not just the graph."

"The average hides the people who had a bad time. If most requests take 200 milliseconds and a handful take ten seconds, the average can still look fine, but those users are the ones who complain or leave. A percentile tells you how bad it gets for a given share of users. The 95th percentile is the time that 95 out of every 100 requests came in at or under, so only 5 in 100 were slower. That's why most targets are written as percentiles, like p95 under two seconds. When I report, I show the median for the typical experience, p90 or p95 for the target, p99 for the tail, and the max, and I look at the gaps between them. A big gap between the median and p99 tells me something is slow now and then, and that's worth digging into."

"They're tied together by Little's Law. The number of users in the system equals the throughput multiplied by the time each one spends per cycle, and in a load test that cycle is response time plus think time. So if I have 100 users, each request takes one second and they think for four seconds, the throughput works out at 100 divided by five, which is 20 requests a second. It's useful in two ways. Before the test, it tells me how many virtual users I need for a target rate. After the test, it's a sanity check: with a fixed number of users, if response times go up, throughput has to fall. If my results show throughput unchanged while response time doubled, something in the test or the numbers is off, and I'd check that before reporting anything."

"Error rate is failed requests over total requests, usually shown per transaction and over time. The catch is what counts as failed. By default JMeter marks a sample as failed on connection errors and 4xx or 5xx status codes. But plenty of apps return HTTP 200 with an error page, or quietly send you back to the login page when the session broke, and the tool counts that as a pass. Those fake passes are often very fast, so they make response times look better too. So on every key request I add assertions: check the status code, look for text that only appears on success, like an order number, and sometimes check the response size. When I report, I break errors down by type and by when they started, because five errors spread across an hour and five hundred in the last ten minutes are very different stories."

"JMeter records three timings for each sample. Connect time is how long it took to set up the connection, including the TLS handshake on HTTPS. Latency runs from just before the request is sent until the first part of the response comes back, so it includes the connect time plus the time the server spent before it started replying. Elapsed time runs until the last byte arrives, so it adds the time to download the whole body. If connect time is small but latency is high, the server is slow to start answering. If latency is fine but elapsed is big, it's a large payload or a slow link. One thing I always point out is that JMeter doesn't render pages or run JavaScript, so elapsed is the time for that request as seen from the load machine, not the page load a user sees in a browser."

"Each thread is one virtual user that runs through the samplers in the thread group in order, so the number of threads is how many users are active at full load. Ramp-up period is how many seconds JMeter takes to start them all, spread evenly, so 100 threads with a 50 second ramp-up starts a new user every half second. I always use a ramp-up, because starting everyone at once is a spike test by accident, and a gradual ramp shows me where response times start to bend as load grows. Loop count says how many times each user repeats the journey. For real load tests I usually set it to infinite and use the thread lifetime duration instead, so the test runs for a fixed time, like an hour at steady load after the ramp."

"At the top is the test plan, which holds one or more thread groups, and each thread group is a set of virtual users. Samplers do the actual work, like an HTTP request or a JDBC query, and logic controllers group them or add loops and conditions. Around each sampler JMeter runs things in a fixed order: config elements like HTTP defaults and the cookie manager, then pre-processors, then timers, then the sampler itself, then post-processors like extractors, then assertions, and finally listeners that collect results. Scope matters too. An element applies to every sampler at its level and below, so a timer placed at thread group level fires before every single sampler, which surprises people. I keep timers and extractors as children of the specific sampler they belong to, so the plan does exactly what it looks like it does."

"Correlation means capturing a value the server generates at run time and sending it back in later requests. A recorded script is full of values like session IDs, CSRF tokens or order IDs that were only valid for that one recording, so if I replay it with fifty users the server rejects them. To find them, I record the flow twice and compare, or search for long random-looking strings in the requests. Then I find the first response that returns the value and add an extractor to that sampler: a JSON Extractor for an API, a Regular Expression or Boundary Extractor for HTML. It saves the value in a variable, and I replace the hard-coded value in later requests with that variable. I always set a default like NOT_FOUND and add an assertion, so if extraction fails the test fails loudly instead of sending garbage."

"I use a CSV Data Set Config. I put the test data in a file, like username, password and customer ID per line, and name the variables in the config. Each time a thread starts a new iteration it takes the next line, and I reference those variables in the requests. The settings that matter are sharing mode, recycle on end of file, and stop thread on end of file. With the default sharing across all threads, each read takes the next line, so users get different rows, and with plenty more rows than active users, two users almost never hold the same account at once. If the data can be reused, I let it recycle. If each line can only be used once, like a one-time voucher, I turn recycling off, stop the thread at end of file, and make sure the file has enough rows. One account for everyone mostly tests the cache and session locking, not the real system."

"The GUI is for building and debugging the script with a handful of users. At real load, the GUI and listeners like View Results Tree hold responses in memory and eat CPU, so the load machine itself becomes the bottleneck and the timings get skewed. So I run from the command line in non-GUI mode. I pass the test plan and a results file, and ask JMeter to build the HTML dashboard at the end into an empty folder. I also pass the thread count, ramp-up and duration as properties, so the same plan can run a small smoke test or a full load test without editing it. And I disable heavy listeners in the plan, because in non-GUI mode the results file is all I need, and I can rebuild the report from it later."

"In distributed mode there's one controller and several worker machines running the JMeter server. The controller sends the test plan to every worker, each one runs it, and results stream back to the controller. The first trap is the maths: each worker runs the whole plan, so if the thread group says 100 threads and I have four workers, that's 400 users, not 100. The second is data. CSV files aren't copied across, so each worker needs its own file at the same path, and if logins must be unique I split the data so workers don't overlap. Then there's the plumbing: the same JMeter and Java versions everywhere, and the RMI ports open through firewalls. Finally I watch the workers' CPU, memory and network during the run, and keep them close to the system under test on the network, so I'm measuring the app and not a long network path."

"I start with data, not guesses. I'd pull production access logs and analytics for the busiest period, usually the peak hour of the peak day, and if the app is new I'd use business forecasts and similar systems. From that I pick the handful of user journeys that carry most of the load or most of the risk, like browse, search, add to cart and checkout, and work out the mix, say for every ten visitors who browse, three search and one buys. For each journey I note the transactions per hour at peak, the typical think time between steps, and how many users are active at once. I also note the data spread, like how many different products get viewed, because hitting the same item every time only tests the cache. Finally I agree a growth factor with the business, so we test for next year's peak, not last year's."

"Think time is the pause between steps inside a journey, like the few seconds someone spends reading a product page before clicking add to cart. Pacing is about the whole iteration: it sets how often each virtual user starts the journey again, so with sixty seconds of pacing that user starts a new journey once a minute, however fast the steps went. Together they let me hit a target transaction rate with a realistic number of users. If I leave them out, each virtual user fires requests back to back, so fifty virtual users can generate the traffic of hundreds of real people. The server sees a pattern no real crowd makes, fewer open sessions but a much higher rate, and the results don't tell you much about the real peak. I also add some randomness to think time so users don't all click in lockstep."

"In a closed model I have a fixed pool of users, and each one waits for its response before sending the next request. In an open model requests arrive at a set rate however the system is coping, which is closer to a public website where new visitors keep turning up. The difference shows when the system slows down. In a closed model, slow responses mean each user sends fewer requests, so the load quietly drops just when the system is struggling, and the requests that would have been sent during the stall are never measured. That's often called coordinated omission, and it makes latency look better than real users would see. In an open model the requests keep coming, queues build, and you see the real pain. So for public traffic I prefer an arrival-rate model, and for an internal system with a fixed number of staff, a closed model can be the honest one."

"First I turn the target into a rate per second: 7,200 orders an hour over 3,600 seconds is two orders a second. Each virtual user takes about 90 seconds per journey, including think time. Little's Law says users equal rate times time in the system, so two times 90 gives 180 virtual users. That's the minimum. Under load the responses may slow down, which stretches each iteration and drops the rate. So I'd trim the think time a little and use pacing to hold each iteration at 90 seconds, which leaves some slack to absorb slower responses, and I might add a few spare users. During the run I'd check the actual orders per second against the target. If we're short and the app is slow, that's a finding. If we're short and the app looks fine, the test needs more users."

"That pattern means something is saturated: work is queueing, so each request waits longer but no more requests finish per second. First I note the load level at the knee. Then I go tier by tier, from the load balancer to the app servers to the database, and for each one I check utilisation, saturation and errors on CPU, memory, disk and network. If CPU is pinned on the app servers, I'd profile the code. If CPU is low everywhere, it's usually a queue: worker threads all busy, the database connection pool empty with requests waiting for a connection, lock contention, or a slow downstream service. APM traces help a lot here, because they show where the time inside each request actually goes. Then I prove it with one change, like a bigger pool or a missing index, and re-run. If the knee moves up, we found it, and often the next bottleneck appears right behind it."

"A steady median with regular p99 spikes tells me most requests are fine and something periodic hurts a few of them. So I'd plot the raw response times over time, measure the gap between spikes, and look for anything on that same cycle. The usual suspects are garbage collection, especially long collections that pause the app; cache entries that all expire at once, so a wave of requests hits the database together; scheduled jobs like reports or backups running against the same database; log rotation or disk flushes; connection pools recycling connections on a timer; and autoscaling adding or removing instances. I'd line up GC logs, job schedules and infrastructure events against the spikes. Once the timing matches one of them, the fix is usually clear, like tuning the collector, staggering cache expiry, or moving the job away from peak hours."

"A run has phases: ramp-up, a steady state at target load, and ramp-down. The question 'do we meet the target at peak load' is answered by the steady state, so that's the window I use for the headline numbers. The first minutes are usually slower because caches are cold, connection pools are still opening and, on some runtimes, code is still being compiled, so including them makes results look worse than a warmed-up production system. Ramp-down numbers mislead too, because load is falling. But I don't throw the rest away. The ramp-up is where I see response time start to bend as users increase, which hints at where the limit is. And in the report I say exactly which window I used, so nobody thinks I picked the best-looking ten minutes."

"I'd lead with the answer, not the charts. The first few lines say plainly whether we met each agreed target, something like: checkout meets its target at the planned peak, but search slows past its target once we reach about four fifths of peak. Then I'd show a small number of charts that tell the story, like response time and throughput as users increase, with the target line drawn on, and how this build compares with the last release. After that come the risks in plain words: what the bottleneck is, what it means for users, and how the test environment differs from production. I finish with recommendations and owners, like adding an index before release and retesting after the fix. The detailed tables and raw data go in an appendix for the engineers, so the main report can be read in a couple of minutes."

"The closer the environment is to production, the more the numbers mean. What I care about most is the same software versions and configuration, like pool sizes and memory settings, similar hardware per server, and the same shape, with the load balancer, cache and database set up the same way. Data volume is huge: a query that's instant on ten thousand rows can crawl on fifty million, so I want a production-sized, anonymised database. For third parties like a payment gateway I use stubs, but I give them realistic response times, because a stub that answers instantly hides real waiting. I also make sure nobody else is running tests on the environment during my run. If it's smaller than production, say half the servers, I don't just double the result. I measure capacity per server and write every difference and its likely effect in the report."

"'Fast' can't pass or fail, so I'd sit down with the stakeholder and make it measurable. First, which transactions matter: login, search and checkout usually have different expectations, and a report export can take longer. Then for each one I write a full statement: the percentile, the time, the load level, the error limit and how long it has to hold. For example, checkout p95 under two seconds at 50 orders a second, with fewer than one error in a thousand requests, held for an hour. The load level comes from production data or forecasts, and the time targets from what users tolerate and what the system does today, so we don't get worse. I also ask about resource headroom, like CPU staying at a comfortable level at peak. Then we agree it in writing before testing, so a result is a clear pass or fail, not a debate."

"JMeter is the most established. It has a GUI for building plans, supports protocols beyond HTTP like JDBC and JMS, and has a large plugin ecosystem. The trade-offs are that plans are XML files that are awkward to review, and each virtual user is a thread, so it needs more memory per user. k6 is code first: tests are JavaScript, it runs from the command line, and thresholds decide pass or fail, which fits nicely into a CI pipeline. Gatling is also code first, with a DSL, and its non-blocking engine can drive a lot of users from one machine, with good HTML reports. I'd pick JMeter when testers want a GUI or we need less common protocols, and k6 or Gatling when developers own the tests and we want them in the pipeline. Honestly, what the team already knows often decides it."

"In k6 the load profile and the pass rules live in the exported options. I use stages to ramp up to 50 users over a minute, hold for five minutes, then ramp down. In thresholds I say the 95th percentile of request duration must stay under 500 milliseconds and failed requests must stay under one in a hundred. The default function is what each virtual user repeats: it makes the request, uses check to confirm the status is 200 and the body has what I expect, then sleeps a second as think time. Checks on their own don't fail the run, they only record a pass rate, so the thresholds are what make it fail. If any threshold is crossed, k6 ends with a non-zero exit code, so the pipeline step fails without anyone having to read a graph."

"At my last company we were launching a new order-tracking API before a seasonal peak. The business expected about three times normal traffic, so I agreed targets with the product owner: p95 under one second for the two main calls at that load, with fewer than one error in a thousand. I pulled a week of access logs to get the mix, mostly status lookups with some history queries, and built the JMeter plan with a CSV of real, anonymised order numbers so we weren't just hitting the cache. We ran a load test at peak, then a stress run past it, all in non-GUI mode. The history call missed its target at peak, and traces showed a query scanning a large table. The team added an index, I re-ran, and it passed comfortably. If I did it again, I'd get production-sized data in place earlier."

"On a booking system I tested, search response times were fine up to about 150 users, then climbed steeply while throughput went flat. The odd part was that CPU on the app servers was only about half used and the database looked quiet. I took thread dumps from the app during the run, and most worker threads were waiting for a database connection. The pool was set to 20 connections, copied from a template, and each search ran two queries. So the database was fine, it just wasn't being asked. I shared the thread dumps and pool metrics with the developers, we raised the pool size to what the database could safely handle, and I re-ran. The knee moved out past 400 users, and the next limit was real database CPU. After that we added pool usage to the standard monitoring dashboard."

"We once passed a load test for a reporting feature, and then at the first month-end in production it slowed to a crawl. When I dug in, the gap was in my workload model. I'd built it from an average week of logs, and month-end looked completely different: finance users ran big exports at the same time, and each one held database locks that blocked normal users. None of that was in my test. I owned it in the review and changed three things. We started building the workload model from the peak business period, not a typical week, and asked the business about calendar events up front. We added the export journey as background load running alongside the normal mix. And we began comparing test assumptions with production monitoring after each release. The next month-end went through without trouble."

"I wouldn't refuse, and I wouldn't just point a tool at the homepage either. I'd ask the manager for fifteen minutes to find out what decision the test feeds, like whether a release can go out or whether we can handle a marketing campaign. Then I'd pin down the minimum: the two or three journeys that matter most, the expected peak, taken from logs if they exist, and a rough idea of acceptable response times. If they can't give targets, I'd propose some based on how production behaves today and get a quick yes. Then I'd scope a test I can do properly by Friday, maybe one run at expected peak and a short step-up to see where it bends. In the report I'd list every assumption clearly, so nobody reads a quick check as full sign-off."

"I wouldn't quietly pass it, and I wouldn't block the release on my own either. First I'd check the result is real: was it consistent across runs, and was anything odd in the environment or the load generator during that test? If it's genuine, I'd size the risk. How far over the target is it, at what load does it cross the line, and how often does production actually reach that peak? Just over target at the very top of forecast peak is a different risk from failing at normal traffic. Then I'd take that to the release owner with options, like releasing with close monitoring and a rollback plan, releasing with a known fix to follow, or delaying. My job is to make the risk clear and honest. The decision belongs to the people accountable for the release, and I'd make sure it's written down."

"I'd take it seriously, because they could be right. A load machine that's out of CPU or memory, or pausing for long garbage collections, adds its own delay to every measurement. So I'd share the load generator's own metrics from the run: CPU, memory, network and, for JMeter, its heap and GC activity. Then I'd compare the tool's timings with the server's own view, from access logs or APM traces, which record how long the app took to handle each request. If the server-side times are also high, the slowness is in the app. If the server says it answered in 100 milliseconds and the tool says two seconds, the problem is somewhere between them, the generator or the network. To settle it, I'd re-run with the load spread over more machines. If the numbers don't change, it isn't the tool. And I'd invite the developer to look at the data with me."