Performance Testing Interview Questions India 2026: JMeter, Load Testing, and Percentile Metrics

Understanding the different types of performance tests and when to use each is the first thing interviewers ask.

Types of performance testing:

1. Load testing: verify the system meets performance requirements under the expected production load (e.g., 500 concurrent users, 1000 requests per second). Goal: confirm the system behaves correctly and within SLA under normal conditions
2. Stress testing: push the system beyond its normal capacity to find the breaking point (at what load does it fail?). Goal: understand failure behaviour and ensure graceful degradation
3. Spike testing: simulate a sudden, sharp increase in load (e.g., a flash sale or a viral event). Goal: test how the system handles unexpected traffic surges and recovers afterward
4. Soak testing / Endurance testing: run at normal load for an extended period (8-24+ hours). Goal: detect memory leaks, connection pool exhaustion, gradual performance degradation, and resource accumulation bugs that only appear over time
5. Volume testing: test with a very large data set to check performance at scale (e.g., a database with 100 million records)
6. Scalability testing: gradually increase load to understand how the system scales — does adding resources improve performance linearly?
7. Breakpoint testing: a form of stress testing that slowly increases load until the system breaks

Key performance metrics:

1. Latency (response time): the time from the client sending the request to receiving the complete response. Measured in milliseconds. Reported as average, median (p50), p90, p95, p99
2. Throughput: the number of successful requests the system processes per second (requests/second or transactions/second). A system can have low latency and low throughput or high latency and high throughput
3. Concurrent users: the number of users simultaneously interacting with the system
4. Error rate: percentage of requests that return an error (5xx, connection timeout); target is usually below 0.1-1% under load
5. Saturation: the degree to which a resource is fully utilised; once a resource saturates (CPU at 100%, connection pool full), latency spikes and errors begin

Percentile metrics:

1. p50 (median): 50% of requests complete within this time. Half the users experience this latency or better
2. p95: 95% of requests complete within this time. Represents the experience of most users, excluding the slowest 5%
3. p99: 99% of requests complete within this time. Captures tail latency — the worst experience that a small fraction of users face. Critical for payment and financial transaction systems where every user matters
4. Why p99 matters more than average: an average can hide a long tail of slow responses; if 1% of transactions in a payment system take 30 seconds, thousands of users per day have a terrible experience even if the average is 200ms

Apache JMeter is the most widely used open-source performance testing tool in India. Knowing its components and how to structure a test plan is essential.

JMeter test plan hierarchy:

1. Test Plan: the root container; defines global variables and serialisation/parallelisation settings
2. Thread Group: defines virtual users; parameters: Number of Threads (virtual users), Ramp-Up Period (seconds to reach the full thread count), Loop Count (how many times each thread runs the test)
3. Controller: controls the flow of requests: Loop Controller (repeat), If Controller (conditional), Transaction Controller (group samplers into a transaction for unified reporting)
4. Sampler: sends a request; the HTTP Request Sampler is the most common; also JDBC (database), JMS (messaging), TCP
5. Config Element: provides configuration to samplers: HTTP Header Manager, HTTP Cookie Manager, HTTP Cache Manager, CSV Data Set Config (for parameterising test data from a CSV file)
6. Listener: records and displays results: View Results Tree (detailed request/response for debugging), Summary Report (aggregated statistics), Aggregate Report (percentile breakdown), Response Time Graph
7. Timer: adds delay between requests to simulate user think time: Constant Timer, Gaussian Random Timer (random delays following a normal distribution)
8. Assertion: validates responses: Response Assertion (check response body, headers, or code), Duration Assertion (fail if response exceeds a time threshold)
9. Pre-Processor and Post-Processor: modify requests before sending or extract data from responses (e.g., Regular Expression Extractor to capture a session token from a login response)

JMeter key concepts:

1. Correlation: extracting dynamic values from responses (session IDs, CSRF tokens, auth tokens) and using them in subsequent requests. Use Regular Expression Extractor or JSON Extractor
2. Parameterisation: using different test data for each virtual user; implemented with CSV Data Set Config; each thread reads a different row from the CSV
3. Think time: the realistic delay between user actions; simulate with timers to avoid creating unrealistically high loads
4. Ramp-up: gradually increase the number of virtual users over the ramp-up period rather than starting all threads simultaneously; avoids an artificial spike at test start
5. Distributed testing: one JMeter master coordinates multiple JMeter agent (slave) machines to generate load beyond a single machine's capacity
6. Command-line mode: jmeter -n -t testplan.jmx -l results.jtl — run JMeter headless in CI environments

The Apdex score and bottleneck identification are advanced topics that separate experienced performance testers from beginners.

Apdex (Application Performance Index):

1. A standardised measure of user satisfaction based on response time; ranges from 0 (worst) to 1 (perfect)
2. Define a target response time T (e.g., 500ms for a web page)
3. Satisfied: response time <= T
4. Tolerating: T < response time <= 4T
5. Frustrated: response time > 4T (or the request resulted in an error)
6. Apdex = (Satisfied + 0.5 * Tolerating) / Total Requests
7. Industry benchmark: Apdex >= 0.94 is Excellent, 0.85-0.94 is Good, 0.70-0.85 is Fair, below 0.70 is Poor

Bottleneck identification:

1. CPU saturation: CPU usage at 100%; all requests are queued waiting for CPU time. Diagnose: server metrics (top, vmstat); solutions: optimise code, add more CPU cores, horizontal scaling
2. Memory pressure: high memory usage causes garbage collection pauses (Java/Node.js) or swapping. Diagnose: free -h, GC logs; solutions: reduce object allocation, increase heap size, fix memory leaks
3. Database bottleneck: most common bottleneck; slow queries, missing indexes, connection pool exhaustion. Diagnose: slow query log, explain plan, connection pool metrics; solutions: add indexes, optimise queries, increase connection pool size, add read replicas
4. Network I/O: high network bandwidth utilisation or many connections. Diagnose: netstat, connection counts; solutions: reduce payload size, connection pooling, keep-alive connections
5. Thread pool exhaustion: all application threads busy processing requests; new requests queue up. Diagnose: thread dump, thread pool metrics; solutions: increase thread pool size, reduce response time to free threads faster

Performance testing process:

1. Define performance requirements: agree on SLA (e.g., p95 < 500ms, throughput > 200 rps, error rate < 0.1%) before testing
2. Identify scenarios: determine which user journeys to test (login, product search, checkout, payment); focus on the critical path
3. Baseline test: run a single-user test to establish baseline latency without load
4. Load test: gradually increase load to the target; monitor for degradation
5. Stress test: exceed the target to find the breaking point
6. Analyse results: look for the inflection point where latency increases non-linearly; that is the saturation point
7. Report findings: percentile breakdown, throughput at different load levels, error rate, identified bottlenecks, and recommendations
8. Retest after fixes: performance testing is iterative; always retest after applying optimisations