Performance Testing Interview Questions and Answers

Start with a baseline load test. Then add stress, spike and soak tests based on risk.

What they are checking: Do you know the test types and what each one is for?

Performance testing measures how a system behaves under a given workload. It looks at speed, stability, scalability and resource use. It does not look for functional bugs. It looks for slow responses, errors and capacity limits.

It matters because slow or unavailable systems lose users and money. Some problems show up only when many users connect at once. Examples are connection pool limits or missing indexes. Testing before release helps you choose the right server size. It also helps you set realistic service level objectives (targets for speed and errors). And it helps you avoid production incidents.

What they are checking: Can you explain the purpose in business terms?

• Response time: the total time from sending a request until the full response is received. This is what the user sees.
• Latency: the delay before the first byte arrives (network time plus server wait time). It is often reported as time to first byte.
• Throughput: how much work is done in a set time, such as requests per second or transactions per second.

They affect each other. As load grows, throughput rises until the system is full. After that, response time climbs and throughput stays flat or drops. Always report them together.

What they are checking: Do you use the terms correctly?

Averages hide slow outliers. Say 95 percent of requests take 200 ms and 5 percent take 8 seconds. The average looks fine, but one user in twenty has a bad experience.

• p50 (median): the typical experience.
• p95 / p99: what the slowest 5 or 1 percent of users get.
• Max: the worst case. It is often noisy.

Service level objectives are normally set on percentiles. For example: "p95 under 500 ms and error rate under 1 percent". Also look at the full spread of results, not just one number.

What they are checking: Do you know why averages can mislead?

• Thread Group: sets the virtual users, the ramp-up period, and the loop count or duration.
• Samplers: send requests (HTTP Request, JDBC, JMS).
• Config Elements: shared settings (HTTP Request Defaults, HTTP Cookie Manager, CSV Data Set Config, Header Manager).
• Logic Controllers: control the flow (Loop, If, Transaction, Random).
• Timers: add a delay or think time between requests.
• Pre/Post Processors: prepare or extract data (Regular Expression, JSON Extractor).
• Assertions: check that responses are correct.
• Listeners: collect and show results (Summary Report, Aggregate Report, Backend Listener).

Execution order: config elements, pre-processors, timers, sampler, post-processors, assertions, listeners.

What they are checking: Do you know the JMeter building blocks?

Key settings:

• Number of Threads: the virtual users.
• Ramp-up period: the number of seconds JMeter takes to start all threads.
• Loop Count: how many times each thread repeats the plan, or infinite.
• Optionally Duration and startup delay, using the scheduler.

Ramp-up avoids hitting the server with all users at the same moment. With 100 threads and a 50 second ramp-up, JMeter starts two users per second. Each thread then runs the plan until the loops or duration end. For steady-state tests, use a long enough duration. Leave the ramp-up out of your analysis.

What they are checking: Can you set up realistic load?

Parameterisation replaces fixed values with variable data. Each virtual user then sends different input, such as usernames, search terms or product ids.

Use CSV Data Set Config:

• File: users.csv with header username,password.
• Variable names: username,password, then use ${username} and ${password} in samplers.
• Recycle on EOF and Stop thread on EOF: choose based on whether the data may be reused.
• Sharing mode: all threads, so each user takes the next row.

Other options: __Random, __RandomString and __UUID functions, User Defined Variables, and the Counter element. Use enough unique data so that caching does not change the results.

What they are checking: Can you create realistic load data?

Assertions confirm that a fast response is also a correct one. A server that returns quick 500 errors would otherwise look great.

The GUI uses a lot of CPU and memory. This limits the load you can create and makes measurements wrong. Use the GUI only to build and debug scripts. Run real tests from the command line.

Think time simulates the pause real users take between actions. Without it, each virtual user sends requests back to back. This creates far more load per user than in real life. So the results are not realistic.

k6 tests are written in JavaScript. A test defines options and a default function. Each virtual user runs that function again and again.

Monitor every tier. Match the data to the test timeline.

Start with the conclusion, then give the evidence.

Concurrent users is how many users are active in the system at the same time. Requests per second is how much work reaches the server each second.

Use post-processors on the sampler:

A baseline is the measured performance of the system under a set load at one point in time. It is usually the current release. You compare later builds to it to find regressions (things that got worse) or improvements. A benchmark is a standard or target to compare against. It can be an industry figure, a competitor, or an agreed service level objective.

Correlation means capturing a changing value from one response and using it in later requests. Examples are a session id, CSRF token, order id or auth token. Without it, replayed requests fail because the recorded values are old.

Steps:

1. Record or build the flow. Compare two runs to spot values that change.
2. Add a post-processor to the sampler that returns the value: JSON Extractor ($.access_token), Regular Expression Extractor (name="csrf" value="(.+?)"), or CSS/JQuery Extractor.
3. Store it in a variable, for example token.
4. Use it later as ${token}, for example in a header Authorization: Bearer ${token}.
5. Add a Response Assertion to confirm the extractor found a value.

k6 uses the same idea. You read the response and pass the value to the next call.

What they are checking: Can you handle values that change?

Planning starts with non-functional requirements and real usage.

• Gather goals: business-critical flows, expected users, peak periods, growth, and agreed service level objectives.
• Use production logs and analytics to learn concurrent users, requests per second, transaction mix and think times. A mix could be 60 percent browse, 25 percent search, 10 percent cart, 5 percent checkout.
• Choose test types: baseline, load at expected peak, stress, spike and soak.
• Environment: as close to production as possible in size, data volume and configuration. Note any differences.
• Data: realistic volumes and unique users.
• Monitoring, entry and exit criteria, schedule, risks, and who is on call.

The output is a test plan and a workload table. Stakeholders approve them before scripting.

What they are checking: Do you plan from requirements and real traffic?

• Slow queries: missing indexes, full table scans, inefficient joins, SELECT *.
• N+1 query patterns from the application.
• Lock contention and deadlocks under many writes at once.
• Connection pool exhaustion or too many connections.
• Large transactions, missing pagination, or growing tables.
• Poor cache hit rates, and replication lag on read replicas.

• Stages ramp virtual users up and down over time to set the shape of the load.

Do not log in on every iteration, unless login is what you are testing.

One load generator is limited by its CPU, memory and network. For higher load, use a controller and several workers.

Little's Law: N = X x R. N is the average number of users (or requests) in the system. X is throughput. R is the average time each one spends in the system (response time plus think time).

A pool has a fixed number of connections or threads. When all are busy, extra requests wait in a queue or fail. Latency grows while CPU can stay low.

Use layers: small checks on every build, bigger tests on a schedule.

Load testing measures how servers behave under many users. Front-end performance measures how fast a single page feels in a browser.

Tools: Lighthouse and PageSpeed Insights, WebPageTest, Chrome DevTools performance panel, and real user monitoring.

• Closed model: a fixed set of virtual users. Each one sends a request, waits for the response, thinks, then repeats. If the server slows down, the request rate drops by itself.
• Open model: requests arrive at a fixed rate, even when responses are slow. This is like real internet traffic. If the server slows down, requests pile up.

Use production-sized, realistic data. Queries that are fast on 1000 rows may be slow on 50 million.

Caches can make test results look much better than real life if the test reuses the same data.

I follow a repeatable process:

1. Define goals: critical transactions, user counts and targets (for example p95 under 500 ms, error rate under 1 percent, 300 requests per second).
2. Build a workload model from production analytics: transaction mix, peak users and think times.
3. Prepare a production-like environment and test data. Make sure the load generator is not the bottleneck.
4. Script in JMeter: samplers, correlation, parameterisation, assertions and timers.
5. Run a smoke test, then baseline, load, stress and soak runs in non-GUI mode.
6. Monitor servers, application and database (CPU, memory, GC, connection pools, slow queries).
7. Analyse and report.

Metrics to report: throughput, average and p90/p95/p99 response times per transaction, error rate and error types, active users over time, and server resource use. Also add what you saw, the bottlenecks found, risks and advice.

What they are checking: Can you plan and report a complete test?

I work from the symptom down to the layer.

Plan capacity from the expected peak and test beyond it.

Low CPU with a throughput ceiling means the system is waiting, not computing. Likely causes:

• Connection pool exhausted (database or HTTP client), so threads queue.
• Thread pool or worker count too small, with requests waiting in the server.
• Lock contention, synchronised sections, or a single-threaded component. -...

That pattern suggests a memory leak or a cache with no size limit.

First, sort the errors into types.

Use Little's Law with the full user cycle.

• Requests per second per user = 1 / (response time + think time).
• Say the average response time is 0.4 s and think time is 3.6 s. A cycle is 4 s, so one user makes 0.25 requests per second.
• Users needed = 500 / 0.25 = 2000 virtual users.

Performance results are valid only if the environment is like production. This covers hardware, configuration, database size, network and third-party setup.

Test at several levels. The slowest service or dependency often limits the whole chain.

Stay calm, put numbers on the problem and give options.