Question 1

How do you analyze production APM access logs and user journey funnels to design a realistic Performance Workload Model, extracting request distributions, peak hourly transactions, and user pacing intervals for an upcoming marketing campaign?

Accepted Answer

Start by pulling raw access-log or APM transaction data for a representative recent period and group requests by URL pattern into logical business transactions rather than raw endpoints — collapse `/product/123`, `/product/456`, etc. into one `view_product` transaction. From there compute the request mix: what percentage of total traffic each transaction represents, because a workload model is a distribution, not a flat number of users.

Then pull two more things from the same logs: peak hourly (or peak 5-minute, extrapolated) transaction volume — using the busiest window, not the daily average, since that's what actually causes outages — and inter-request pacing, i.e. the gap between consecutive requests from the same session, grouped by session ID or cookie, to derive realistic think time.

For example, if logs show homepage=40%, search=25%, product view=20%, add-to-cart=10%, checkout=5%, with a peak hour of 180,000 requests and a 45-second average think time between actions, your load-test script should replicate that exact transaction ratio per virtual-user iteration, a gaussian think-time distribution centered on 45s, and a load level reproducing 180k requests/hour — then scaled by whatever growth factor marketing expects for the campaign, e.g. 3x last year's comparable peak.

Question 2

A target system must achieve 1,200 Transactions Per Second (TPS) on a checkout transaction where average response time is 250ms and user think time is 4.75 seconds. Apply Little's Law to calculate the exact number of concurrent Virtual Users (VUs) required in the load test.

Accepted Answer

Little's Law states L = λ × W, where L is the number of items in the system (here, concurrent VUs), λ is the arrival rate/throughput (TPS), and W is the average time each item spends in the system.

The key detail people get wrong is that W must include think time, not just response time — a virtual user isn't 'in the system' only while waiting for a response, it's occupied for the response time PLUS the time it pauses before its next request. So W = 0.25s (response time) + 4.75s (think time) = 5 seconds.

VUs = λ × W = 1,200 × 5 = 6,000 concurrent virtual users needed to sustain 1,200 TPS. If you'd used response time alone (0.25s), you'd wrongly conclude only 300 VUs are needed — which would generate nowhere near 1,200 TPS in practice because each VU spends 95% of its cycle idling in think time, not making requests.

Question 3

Design a distributed performance testing architecture that generates load from 5 distinct global regions simultaneously to test latency and CDN edge caching for a global video streaming platform without bottlenecking the load generator instances.

Accepted Answer

Deploy independent load-generator pools in each of the 5 target regions (e.g., cloud VMs or containers in AWS ap-south-1, eu-west-1, us-east-1, sa-east-1, ap-northeast-1) so traffic genuinely originates from that geography and hits the nearest CDN edge, rather than simulating geography by adding artificial latency from one central location. A central controller coordinates start time (NTP-synced) so all regions ramp together, and each region's injectors size themselves so they never exceed roughly 70% of their own CPU/network capacity — self-monitoring the injector's own health metrics separately from the application's, since a saturated load generator produces fake bottleneck data that looks like an application problem.

Results stream from every region into one shared time-series backend (Prometheus remote-write or InfluxDB) tagged by source region, so you can slice p95/error-rate per region afterward — this is what actually reveals CDN edge cache-miss geography (e.g., the sa-east-1 region shows 3x higher latency because that edge PoP has a much lower cache hit ratio for this content).

Concretely, this is the model tools like k6 Cloud, Gatling FrontLine, or a self-managed JMeter/Locust distributed setup with worker fleets per region implement: one control plane, N independent regional injector fleets, one aggregated observability layer.

Question 4

Design a 48-hour Soak (Endurance) Test profile for an enterprise payment engine. What specific system and runtime metrics (e.g., old-generation heap memory, database connection pool leaks, file handle growth) do you monitor to detect slow resource exhaustion?

Accepted Answer

Run the soak test at a steady, realistic load — typically 60-70% of the system's known peak sustainable throughput, not peak — held constant for the full 48 hours, because a soak test is about detecting slow degradation over time, not finding a breaking point. The workload mix should mirror real production traffic patterns including any daily cycle if the test spans multiple days.

The metrics that matter are ones that should be flat or cyclical (sawtooth) under healthy behavior but instead trend upward if something's leaking: JVM old-generation heap usage measured right after each full GC (a healthy system returns to roughly the same floor each cycle; a leak shows that floor slowly rising — 2GB → 2.1GB → 2.3GB → 2.6GB over 48 hours even though load never changed), full-GC frequency and pause duration (rising frequency means the heap is filling faster over time), database connection pool active-vs-idle counts (a leaked connection means the pool creeps toward its max and stays pinned there instead of cycling), open file descriptor / socket count via `lsof`, and thread count (unclosed thread pools accumulate zombie threads).

Response time drift hour-over-hour under constant load is the summary signal: if p95 at hour 2 is 200ms and at hour 40 is 900ms with identical load, something is exhausting a resource, and the granular metrics above tell you which one.

Question 5

Construct a Stress Testing strategy to determine the breaking point of an order-processing service. How do you configure step-up load curves to identify the threshold where latency degrades non-linearly, and verify that the system sheds load or recovers automatically when traffic normalizes?

Accepted Answer

Use a step-up (staircase) load curve rather than one continuous ramp: increase virtual users in fixed increments (e.g., +200 every 10 minutes) and hold each step long enough for the system to reach steady state before adding the next increment. This lets you attribute a latency change to a specific load level instead of a moving target.

Plot response time against concurrency for each step — the breaking point is the step where the curve stops being roughly linear and bends sharply upward, which usually correlates with a specific resource hitting saturation (DB connection pool maxed, thread-pool queue filling, CPU pegged). Push one or two steps past that point deliberately to observe failure mode: does the system return fast, explicit rejections (503/429 with Retry-After) and keep serving the requests it does accept at acceptable latency — graceful degradation — or does it accept everything and let all requests slowly time out, cascading failure upstream?

Finally, step load back down to baseline and verify recovery: throughput and latency should return to their original baseline values within a reasonable window. If they don't — e.g., the connection pool stays exhausted or a circuit breaker stays open — that's a real production risk, since it means a temporary traffic spike could leave the system degraded long after the spike itself has passed, requiring a manual restart to recover.

Question 6

During a 5,000 VU load test, response times suddenly spike from 200ms to 8,000ms. Walk through your diagnostic process using APM transaction traces, thread dumps, and database metrics to determine whether the root cause is garbage collection pauses, DB row-level lock contention, or connection pool starvation.

Accepted Answer

First check the APM transaction trace timeline for the exact spike window: does every in-flight request stall simultaneously (a hallmark of GC), or only requests touching a specific table/entity (more consistent with locking or pool exhaustion)? Cross-reference that timestamp against the JVM's GC log — a 'Pause Full (Allocation Failure) 6.2s' entry lining up exactly with the spike confirms garbage collection as the cause.

If GC logs look clean, capture 2-3 thread dumps a few seconds apart during the spike. If most threads share the same stack frame blocked inside `HikariPool.getConnection` (or your pool library's equivalent), that's connection-pool starvation — confirm by checking the pool's active-vs-max metric (active pinned at max, with a growing pending-request queue). If instead threads are BLOCKED on a `synchronized` method or waiting on a DB call executing `SELECT ... FOR UPDATE`, and the database's own lock-wait metrics (e.g., `pg_locks`, InnoDB `lock_wait_timeout` counters) show contention on the same rows/table at that timestamp, that points to row-level lock contention.

The practical rule: GC shows up as a synchronized, application-wide stall visible in JVM logs before you even look at threads; pool starvation shows up as many threads waiting on the pool acquisition call, not on real work; lock contention shows up as threads blocked on actual query execution correlated with DB-side lock-wait metrics on specific rows.

Question 7

A backend microservice reaches 100% CPU utilization at only 20% of its target throughput during a load test. How do you capture and interpret CPU flame graphs and thread state distributions to distinguish between inefficient algorithmic compute loops and thread lock contention overhead?

Accepted Answer

Capture a CPU flame graph during the load (via async-profiler for JVM services, or `perf record`/`perf script` plus a flame-graph generator for native processes) sampled across all threads for a representative window of the test. A flame graph that shows wide, flat plateaus sitting inside application/business-logic method frames — e.g., a nested loop doing repeated string concatenation or an unindexed in-memory search — indicates the CPU is genuinely busy doing (inefficient) real work; that's an algorithmic problem, and profiling will point at the exact method to optimize.

A flame graph instead dominated by frames like `pthread_mutex_lock`, `synchronized` monitor entry, `ObjectMonitor::wait`, or `Unsafe.park`/spin-loop frames means threads are burning CPU cycles fighting over a lock (spinning, context-switching, or busy-waiting) rather than doing useful work — that's contention overhead, and the fix is reducing lock scope/granularity, not optimizing algorithms.

Cross-check with the thread-state distribution: high RUNNABLE thread count with CPU pegged but throughput barely moving suggests threads are 'running' but not making real progress (consistent with spinning on contention), while a healthy CPU-bound workload shows RUNNABLE threads whose count and time correlate directly with throughput gains as you add more of them, up to the core count.

Question 8

A load test running on a single injector machine suddenly begins failing with socket bind errors or connection timeouts. How do you troubleshoot Linux TCP stack parameters (TIME_WAIT reuse settings, ephemeral port ranges) to eliminate client-side load generator bottlenecks?

Accepted Answer

This is almost always the load generator running out of usable local ports, not the server under test — the giveaway is that only the client machine shows errors ('cannot assign requested address') while server-side metrics look completely healthy. Every closed outbound TCP connection sits in the TIME_WAIT state for 2×MSL (default ~60 seconds on Linux) before its ephemeral port can be reused, and the default ephemeral port range (`net.ipv4.ip_local_port_range`, typically 32768-60999, ~28,000 ports) can be exhausted quickly if the test opens a new connection per request at high concurrency.

Confirm with `ss -tan state time-wait | wc -l` (or `netstat`) climbing toward the ephemeral range size as the test progresses. Fixes, in order of preference: enable HTTP keep-alive in the test script so connections are reused instead of opened fresh per request (removes the root cause); widen the ephemeral port range; enable `net.ipv4.tcp_tw_reuse=1` (safe — allows reusing a TIME_WAIT socket for a new outgoing connection when the timestamp math confirms it's safe); and never enable `tcp_tw_recycle` (removed in modern kernels and known to break connections behind NAT even when it existed).

If keep-alive isn't an option because you're deliberately simulating connection churn, the real fix is spreading the test across multiple injector machines/IPs to multiply the total available port pool rather than tuning a single box further.

Question 9

A profile endpoint runs smoothly during functional testing (50ms), but under 500 concurrent users, latency jumps to 4 seconds and database CPU hits 95%. How do you identify an N+1 ORM query loop using database query logs and explain why its performance degrades quadratically under load?

Accepted Answer

Turn on the database's slow-query log with a very low (or zero) threshold against a small repro case and hit the endpoint once — an N+1 pattern shows up immediately as one query for the parent record followed by N nearly-identical queries, one per related row, instead of a single joined/batched query. APM transaction traces make this even clearer by showing a per-request DB-call count (e.g., '47 DB calls' for one endpoint hit), which is the fastest way to spot it without reading raw logs.

It looks fine functionally because in dev/QA the dataset is tiny — one user with 5 related rows means 6 cheap queries, invisible at 50ms. Under 500 concurrent users, two things compound: the query count itself scales with both concurrent users and each user's related-row count (not linearly with users alone), and all of those queries compete for the same finite DB CPU/connection pool, so requests start queueing behind each other — the growth in total DB work isn't just additive with load, it interacts with contention for a shared, saturating resource, which is why observed latency degrades far faster than the raw request count would suggest.

Fix is eager loading/joins, not more DB hardware:
```python
# N+1
users = User.objects.all()
for u in users:
    print(u.profile.bio)  # separate query per user

# Fixed: one query via JOIN
users = User.objects.select_related('profile').all()
```

Question 10

An engineering dashboard shows an average response time of 150ms during a load test, but customer support reports severe delays. Explain why calculating the arithmetic mean masks tail latency, and how evaluating p95, p99, and p99.9 percentiles reveals the true user experience.

Accepted Answer

An average blends every request into one number, so a large majority of fast requests can completely absorb a smaller number of very slow ones. For example, 950 requests at 100ms and 50 requests at 6,000ms still average to about 145ms — the dashboard looks fine, but 5% of real users, which at any real scale is thousands of people, waited six full seconds.

Percentiles report the actual value at a given rank instead of blending everything: p95 = 6,000ms in that example tells you directly that 1 in 20 requests hits 6 seconds, and p99/p99.9 push further into the tail to catch rarer but even worse outliers. Support tickets almost always come from exactly the population percentiles expose and averages hide.

Concretely, on an e-commerce checkout, most carts hit a fast path, but carts that trigger a slower discount-calculation branch (say 5% of traffic) take 6 seconds — the average looks acceptable, the p95 immediately flags the problem, and only percentile-based SLAs (e.g., 'p99 < 1s') would have caught this before it shipped.

Question 11

When analyzing performance test results, plot and explain the relationship between Concurrency, Throughput (TPS), and Response Time (the 'Knee' of the performance curve), identifying the exact transition point from optimal utilization to queue saturation.

Accepted Answer

As concurrency rises from a low starting point, throughput climbs roughly linearly while response time stays essentially flat, because the system has spare capacity and requests aren't waiting for anything. Past a certain concurrency level, some resource (CPU, DB connections, a thread pool) saturates — throughput plateaus because that resource can't process any faster, while response time starts climbing because new requests now queue behind the saturated resource instead of being served immediately. That inflection is the 'knee.'

Push concurrency further past the knee and throughput can actually decline (not just plateau) as retries, timeouts, and contention overhead start consuming capacity that would otherwise go to real work — while response time keeps climbing steeply.

For example, plotting concurrency against TPS and response time on two axes might show TPS rising linearly from 0 to 200 as users go 0→500, flattening around 210 TPS between 500-800 users while response time jumps from 150ms to 2s, and above 800 users TPS actually drops to 180 while response time hits 5s. The knee sits around 500-600 users — that's the system's real safe operating capacity, not the higher number it can technically still accept requests at.

Question 12

During a simulated flash sale load test, an autoscaling Kubernetes cluster drops 15% of requests during the first 3 minutes of traffic surge. How do you measure horizontal-pod-autoscaler metric collection lag, node provisioning delays, and pod startup warmup times to tune autoscaling policies?

Accepted Answer

Break the delay into its three separate stages and measure each independently rather than treating 'autoscaling is slow' as one problem. Metric-collection lag: HPA polls metrics-server on a default interval (commonly every 15s), and metrics-server itself scrapes kubelets on its own interval, so a sudden spike can take 30-60 seconds just to be reflected in a scale-up decision — measure this by comparing the actual traffic-spike timestamp against the HPA's recorded desired-replica-count-change timestamp in its events.

Node provisioning delay: if new pods need new nodes, the cluster autoscaler has to request and boot a new VM from the cloud provider, which commonly takes 1-3 minutes — measure via the time between a pod entering `Pending` (unschedulable) and the new node registering as `Ready`. Pod startup/warmup: image pull time, container boot, readiness-probe pass, plus any application-level cache/JIT warmup before it can serve at full throughput — measure time from pod `Running` to first successful readiness check, and separately, response-time-under-load for the first minute after that.

To tune: pre-scale ahead of known events using a scheduled minimum replica count, use faster-reacting custom metrics (e.g., request-rate-based scaling via KEDA instead of raw CPU, which lags behind demand), keep a small warm-pod buffer, tighten `behavior.scaleUp` stabilization windows in the HPA spec, and reduce `initialDelaySeconds` on readiness probes wherever it's safe to do so.

Question 13

Under high write load, database transaction latency spikes while CPU and memory remain below 40%. How do you analyze disk I/O queue depth, write amplification in write-ahead logs (WAL), and storage IOPS burst credit depletion to diagnose storage tier bottlenecks?

Accepted Answer

Low CPU/memory with high latency under write load is the classic signature of a storage-bound bottleneck, so go straight to disk metrics: `iostat -x 1` and watch `avgqu-sz` (average queue depth) and `%util` — if the block device queue is deep and `%util` sits near 100%, requests are queueing at the disk regardless of how idle the CPU looks.

Write amplification happens because most databases commit via a write-ahead log first (a fast, sequential write) and only later flush the actual data pages (random writes) — under high write volume, the WAL's fsync becomes the serialization point, since it's commonly single-threaded/sequential by design, so `fsync` latency (visible in `iostat`'s `await` column) directly gates how fast transactions can commit, independent of CPU.

Cloud block storage (AWS gp2/gp3, GCP PD) also enforces IOPS burst credits: baseline provisioned IOPS is lower than the burst rate, and sustained heavy writes drain the burst bucket, after which throughput suddenly drops to the much lower baseline mid-test even though load hasn't changed — check your cloud provider's burst-balance metric (e.g., `BurstBalance` in CloudWatch for gp2) to confirm this is what happened rather than assuming it's a database configuration issue.

Question 14

In a recorded load-test script, a user flow fails upon playback because the server rejects static CSRF tokens and session IDs. Walk through extracting dynamic tokens from response payloads using regex or JSON-path extractors and parameterizing subsequent requests.

Accepted Answer

The recorder captured the exact CSRF token/session ID value that was valid at recording time, but the server generates a fresh one on every real session — replaying the hardcoded value fails because the server correctly rejects a token it never issued for this run. The fix is correlation: capture the value dynamically from the response that contains it, then reuse that captured variable in later requests instead of the recorded literal.

In JMeter, add a JSON Extractor (or Regular Expression Extractor for non-JSON responses) directly after the request whose response contains the token — e.g., reference name `csrfToken`, JSON path `$.token` — which stores the extracted value into a variable. Then replace the hardcoded value in every subsequent request with `${csrfToken}`.

Example: the login response body is `{"token":"a1b2c3",...}`; the extractor captures `token` into `${csrfToken}`, and the next request's body becomes `{"token":"${csrfToken}",...}` instead of a fixed string. Session cookies are usually handled automatically by an HTTP Cookie Manager, but hidden anti-forgery fields (like ASP.NET's `__RequestVerificationToken`) need the exact same manual extract-and-reuse treatment.

Question 15

Write a modular performance-as-code load test script that defines a ramping-VUs execution stage, simulates realistic user login actions, and enforces automated pass/fail latency thresholds within a CI/CD pipeline.

Accepted Answer

k6 is built exactly for this: the test is plain JavaScript, `stages` define the ramp profile declaratively, and `thresholds` make the script itself pass/fail so `k6 run` returns a non-zero exit code your CI pipeline can gate on — no separate report-parsing step needed.

```js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp up
    { duration: '5m', target: 100 },   // steady state
    { duration: '2m', target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.post(
    'https://app.example.com/api/login',
    JSON.stringify({ user: 'test', pass: 'test' }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  check(res, { 'login ok': (r) => r.status === 200 });
  sleep(1);
}
```

Wiring it into CI is a single step (`k6 run script.js`) added to the pipeline after deploy-to-staging; because the thresholds fail the process itself, the pipeline step fails the build automatically the moment p95 exceeds 500ms or the error rate exceeds 1%, with no manual result inspection required.

Question 16

How do you deploy and orchestrate distributed load generation tests across a Kubernetes cluster, and how do you stream real-time metrics to a monitoring stack for live test visualization?

Accepted Answer

Install the k6 Operator, which adds a `K6` custom resource to the cluster. A `K6` manifest specifies the test script (usually via a ConfigMap) and a `parallelism` value — the operator schedules that many runner pods, splits the total VU count across them, and coordinates their start/stop via an internal starter job so results represent one coherent distributed run rather than N unrelated ones.

For live metrics, configure k6's output to stream during the run instead of only summarizing at the end — `k6 run --out experimental-prometheus-rw` pushes metrics via Prometheus remote-write as the test executes, or `--out influxdb=http://...` for an InfluxDB backend. Point a Grafana dashboard (the official k6 community dashboard works out of the box) at that same data source, and you get live-updating VUs, RPS, and percentile latency graphs while the distributed run is still in progress.

This setup is what lets you watch p95 climbing in real time across all runner pods combined during a large-scale test, rather than discovering the result only after the run finishes and k6 prints its summary.

Question 17

When load testing an application that depends on a third-party payment gateway with strict rate limits, how do you use service virtualization with injected latency profiles to test internal system scalability without hitting the live third-party API?

Accepted Answer

Stand up a stub server (WireMock or similar) that mimics the payment gateway's API contract — same request/response shapes, same status codes for success and common failure cases — and point your application at that stub instead of the live vendor endpoint for the duration of the load test. This removes the vendor's rate limit and per-transaction cost as constraints entirely, letting you push whatever concurrency your own system needs to be tested at.

Crucially, configure the stub with a realistic injected latency (fixed or randomized within the vendor's typical response-time range) rather than instant responses, because a payment call that returns in 0ms is unrealistic and will make your system look artificially fast — the whole point is exercising your app's real network, serialization, and timeout-handling code paths under a load profile that matches production reality. Also configure a percentage of simulated errors/timeouts so you can verify your own retry and circuit-breaker logic behaves correctly under load, not just the happy path.

Example WireMock stub:
```json
{
  "request": { "method": "POST", "urlPath": "/charge" },
  "response": { "status": 200, "fixedDelayMilliseconds": 350, "jsonBody": { "status": "approved" } }
}
```

Question 18

What is performance testing and why is it important?

Accepted Answer

Performance testing evaluates how a system behaves under expected and extreme conditions — measuring response time, throughput, resource usage, and stability — rather than just checking whether a feature works correctly. It matters because functional correctness says nothing about whether a system stays fast and available when thousands of people hit it at once; a huge share of real production outages are capacity and latency failures, not logic bugs, and those only surface under real load, which functional QA never generates.

For example, a checkout flow can work perfectly for a single QA tester in 200ms, yet take 8 seconds and start timing out for real users during a flash sale, because a database connection pool sized for 20 concurrent testers simply can't serve 2,000 concurrent shoppers. That failure is invisible until someone deliberately performance-tests at 2,000 concurrent users before real customers discover it instead.

Question 19

What is the difference between load testing, stress testing, and spike testing?

Accepted Answer

Load testing verifies behavior at expected/normal peak traffic to confirm SLAs hold under realistic conditions. Stress testing deliberately pushes beyond expected peak, increasing load until the system breaks, to find its ceiling and observe whether it fails gracefully or catastrophically. Spike testing applies a sudden, short burst of extreme traffic — not a gradual ramp — to check whether the system can absorb an abrupt surge and recover afterward, rather than testing sustained high load.

For example, an e-commerce site load-tests at 5,000 concurrent users (expected festive-sale traffic), stress-tests by climbing to 15,000 users to find the breakpoint, and spike-tests by jumping instantly from 500 to 8,000 users in 30 seconds to simulate a viral social post, then dropping back to 500 to confirm the system recovers cleanly.

Question 20

What is the difference between JMeter and LoadRunner?

Accepted Answer

JMeter is open-source and free, Java-based, with protocol support driven by its community/plugin ecosystem (HTTP, JDBC, JMS, and more), scripted via its GUI plus Groovy/BeanShell, and scaled by managing your own distributed worker nodes. LoadRunner (Micro Focus/OpenText) is commercial, licensed by virtual-user count or protocol, and offers deeper native support for legacy enterprise protocols JMeter handles poorly (Citrix thin-client, SAP GUI, RTE), plus a more polished built-in analysis and reporting suite and vendor support — at significant licensing cost.

In practice: reach for JMeter, k6, or Gatling for standard web/API/microservice testing, which covers most modern stacks, and reach for LoadRunner mainly when you must performance-test legacy enterprise protocols that open-source tools genuinely can't script well.

Question 21

What are the key metrics you track during a performance test?

Accepted Answer

Response time (and its percentiles, not just the average), throughput (requests or transactions per second), error rate under load, concurrency/active users, and server-side resource utilization (CPU, memory, disk I/O, network). Alongside these, saturation indicators like database connection-pool usage, thread-pool queue length, and GC pause frequency/duration usually explain why response time and error rate moved the way they did.

For example, a healthy dashboard during a test might show TPS holding at 800, p95 latency at 220ms, error rate 0.02%, CPU at 65%, and DB pool at 40/100 connections. If TPS then plateaus at 800 while concurrency keeps climbing and the DB pool hits 100/100, you've identified the bottleneck metric — the connection pool — before p95 even blows up.

Question 22

What should a performance test plan document?

Accepted Answer

A performance test plan documents the business/NFR goals (target TPS, response-time SLA, concurrent user count), the in-scope transactions and their traffic-mix weighting, the test environment and how closely it mirrors production sizing, the workload model (ramp-up, steady state, ramp-down durations), the tools to be used, entry/exit criteria (pass/fail thresholds), the monitoring plan (which metrics, from where), and the schedule with sign-off ownership.

A concrete exit criterion looks like: 'p95 response time for checkout <= 1.5s and error rate < 0.5% at 2,000 concurrent users sustained for 30 minutes.' A plan without a specific, measurable number like this isn't actually testable — it's just an intention, and different stakeholders will disagree afterward about whether the test 'passed.'

Question 23

What is the difference between throughput, latency, and response time?

Accepted Answer

Response time is how long a single request takes end-to-end from the client's perspective. Latency, strictly, is the network/transport delay component — though it's often used loosely as a synonym for response time — the time for a packet or request to travel, excluding processing. Throughput is a rate: how many requests or transactions the system completes per unit time (TPS/RPS), independent of how fast any single request is.

For example, a system can have low latency (a 50ms network round trip) but low throughput (only 100 TPS, because a single-threaded bottleneck limits it) — fast per request, but unable to handle volume. Conversely, a batch API might have high latency per call (2 seconds) but achieve high throughput via massive parallelism. They're related but genuinely distinct axes, and a good performance report always separates them rather than conflating 'fast' with 'handles a lot.'

Question 24

What is ramp-up period in load testing and why does it matter?

Accepted Answer

Ramp-up is the duration over which virtual users are gradually added at the start of a test rather than all launching at once. It matters because real traffic builds up over time — even a genuine surge grows over seconds or minutes — and a 0-second ramp-up, where all VUs hit simultaneously, creates an artificial thundering-herd effect that can trigger false failures, like connection-pool exhaustion at test-start that would never occur with organic traffic growth. It also doesn't give autoscaling, caches, or JIT compilation time to warm up, producing misleadingly bad early numbers.

For example, testing 1,000 users with a 10-minute ramp-up adds roughly 100 users per minute, letting connection pools grow and caches warm naturally — whereas an instant 1,000-VU launch might report a false 30% error rate purely from every VU opening a TCP+TLS handshake in the same millisecond, not from any real application weakness.

Question 25

How do you gather non-functional requirements (NFRs) for a performance test when none exist upfront?

Accepted Answer

Most organizations don't have documented performance NFRs, so you derive them from several sources: production analytics/APM data giving current real traffic peaks and percentiles as a floor, business projections (expected growth, marketing-campaign multipliers, seasonal peaks), any SLAs already promised to customers or contracts, and industry benchmarks for the domain — e.g., page load under 2-3 seconds for e-commerce, sub-100ms for trading systems. Where none of that exists, fall back to UX research: response times beyond roughly one second start to feel 'not instant' to users, which becomes a defensible target.

For example, for a brand-new feature with zero historical data, you'd combine 'we expect 3x today's peak traffic based on marketing's campaign reach estimate' with 'industry standard for checkout flows is p95 under 2 seconds' to arrive at a concrete NFR, rather than guessing a round number that nobody can justify later.

Question 26

How does performance testing feed into capacity planning?

Accepted Answer

Capacity planning answers 'how much infrastructure do we need for expected future load,' and performance testing supplies the empirical data to answer that credibly instead of guessing — by finding the actual throughput ceiling of a given infrastructure configuration (e.g., 'this cluster sustains 2,000 TPS at acceptable latency before the knee'), you can extrapolate scaling needs for projected growth and validate whether horizontal scaling actually delivers proportional gains, which it often doesn't when a shared resource caps it.

For example, if load testing shows 3 app-server pods sustain 2,000 TPS but 6 pods only reach 2,800 TPS instead of the expected 4,000, that sub-linear scaling reveals the database — not the app tier — is the real ceiling. Capacity planning for next year's projected 5,000 TPS then correctly directs budget toward database read-replicas or sharding, instead of just buying more app-server pods that won't actually move the number.

Question 27

What role does APM play in performance testing?

Accepted Answer

APM tools (New Relic, Dynatrace, AppDynamics, Datadog) provide server-side, code-level visibility that a load-testing tool alone cannot. The load tool gives you the outside view — response time and error rate as the client experiences them — while APM gives the inside view, via distributed traces broken down span-by-span, showing exactly which method, database query, or external call is consuming the time inside that response.

For example, a load test might report checkout p95 = 3.2 seconds; without APM you only know it's slow. With APM's transaction trace for that same request, you can see it breaks down into 200ms of application logic plus 2.8 seconds spent in a single SQL query against the orders table — turning a vague 'it's slow' into an actionable 'this query needs an index,' which is the entire point of running APM alongside a load test rather than treating it as an afterthought.

Question 28

How do you build a performance test environment that's genuinely representative of production?

Accepted Answer

Match production on the dimensions that actually affect performance: the same instance types and CPU-to-memory ratio (not just the same node count), the same database size and data distribution, the same network topology/latency between tiers, and the same configuration — connection-pool sizes, cache TTLs, autoscaling policies. Cost usually makes a byte-for-byte clone impractical, so explicitly document every deviation and treat results as directionally valid only for the metrics that deviation doesn't affect.

For example, if the perf environment's database has 50,000 rows seeded by a script versus production's 40 million real rows, a query that looks instant in the test will silently do a full table scan in production, because indexes and query planners behave completely differently at different data volumes. Anonymized or subset copies of real production data volume — not just a correct schema — is one of the highest-value, most commonly skipped steps in achieving environment parity.

Question 29

What is the difference between parameterization and correlation in load testing scripts?

Accepted Answer

Parameterization is feeding a script different input data per virtual user or iteration from a dataset — e.g., 5,000 distinct usernames from a CSV — so every VU isn't hitting the exact same record, which would create artificial cache hits or unique-constraint failures. Correlation is different: it's capturing a value the server generates dynamically at runtime, like a session token or order ID, from one response and feeding it into a later request, because that value can't be known ahead of time — it doesn't exist until the server creates it.

For example, you'd parameterize the login username per VU (user1@test.com, user2@test.com, ... from a CSV) so 5,000 users don't all try to log into the same account, while separately correlating the session ID that login response returns into subsequent requests, since that token is generated fresh by the server on every run and can never be hardcoded into the script.

Question 30

What is an Apdex score and how is it calculated?

Accepted Answer

Apdex (Application Performance Index) converts raw response times into a single 0-to-1 satisfaction score using two thresholds you define: T, the target time counted as 'satisfied,' and 4T, the boundary for 'tolerating.' Requests faster than T score as satisfied (1), requests between T and 4T score as tolerating (0.5), and requests slower than 4T score as frustrated (0). Apdex = (Satisfied + Tolerating/2) / Total Samples.

For example, with T = 500ms, if out of 1,000 total requests 800 finish under 500ms, 150 land between 500ms and 2,000ms, and 50 exceed 2,000ms: Apdex = (800 + 150/2) / 1000 = 0.875. It's a single trend-able number that's easier for stakeholders to track release over release than staring at raw percentile tables, though it does hide distribution detail that percentiles preserve.

Question 31

How do Core Web Vitals relate to performance testing?

Accepted Answer

Core Web Vitals — LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID), and CLS (Cumulative Layout Shift) — measure real front-end user-experienced performance, a different layer from backend load testing. A backend can handle 10,000 TPS with 50ms server response time and still deliver a terrible Web Vitals score if the frontend ships several megabytes of unoptimized JavaScript that blocks rendering.

They matter for performance testing because they're also a search-ranking and UX signal, so a complete strategy includes synthetic Lighthouse/WebPageTest runs and Real User Monitoring for these metrics alongside backend load tests, not backend load testing alone. For example, a load test might show the API responding in 80ms under load, yet the page's LCP measures 4.5 seconds (poor) because a render-blocking third-party script loads before the main image — a real performance defect a pure backend load test would completely miss.

Question 32

How do you performance test a REST API?

Accepted Answer

Isolate the API from the UI — hit endpoints directly with HTTP calls, skipping browser rendering entirely. Use realistic payload sizes and real, refreshed auth tokens rather than one shared token that becomes a bottleneck or gets rate-limited. Test each endpoint's SLA individually, then run realistic mixed-traffic scenarios matching the production ratio of endpoint calls, and validate not just 2xx-status latency but also error-path behavior (4xx/5xx) and rate-limiting behavior under load.

Example k6 script testing a GET endpoint with auth and a latency threshold:
```js
import http from 'k6/http';
export const options = { vus: 200, duration: '3m', thresholds: { http_req_duration: ['p(99)<300'] } };
export default function () {
  http.get('https://api.example.com/v1/orders', { headers: { Authorization: `Bearer ${__ENV.TOKEN}` } });
}
```

Question 33

How do you performance test a database independently of the application layer?

Accepted Answer

Bypass the application entirely and drive load directly against the database using the actual query patterns the app produces — either replay captured query logs at scale or write scripts (JMeter's JDBC sampler, tools like pgbench/sysbench, or a custom harness) that execute representative queries concurrently with realistic parameter variation. This isolates whether slowness originates in SQL, schema, or indexing versus application code or network overhead.

For example, run pgbench with a custom .sql script replaying your top 10 slowest production queries — extracted via pg_stat_statements — at increasing client concurrency, tracking TPS and latency purely at the database layer. If the database alone chokes at 500 concurrent connections independent of any app server, you've proven the bottleneck is database-side (a missing index, lock contention, connection limit) before spending time chasing it in application code.

Question 34

What is shift-left performance testing?

Accepted Answer

Shift-left means running performance checks earlier in the development lifecycle — per-commit or per-PR micro-benchmarks and small-scale load tests in CI, rather than one big load test the week before release — so regressions are caught while they're still a 10-line diff, instead of buried in months of accumulated changes right before launch.

For example, add a CI step that runs a 2-minute k6 smoke load test (50 VUs) against every pull request's preview environment with a threshold gate (p(95) < 400ms), failing the build if a change regresses latency by 2x. This catches an accidental N+1 query the day it's introduced, rather than during a pre-release performance cycle three months later when tracing it back to its cause is far more expensive.

Question 35

How do you manage test data for large-scale performance tests?

Accepted Answer

Large-scale performance tests need enough distinct, realistic data to avoid three failure modes: unique-constraint collisions (many VUs trying to register the same email), artificial cache hits (everyone requesting the same product ID looks unrealistically fast because it's always warm in cache), and unrealistic data-volume effects (queries against a near-empty table use different execution plans than queries against millions of rows). The fix is generating or seeding synthetic data at production-like volume, using data pools large enough that VUs don't repeat records within a run, and resetting or recycling data between test cycles so results stay repeatable.

For example, a 5,000-VU checkout load test should draw from a pool of 50,000 pre-created test-user accounts with realistic cart histories — not 5,000 accounts reused every iteration, and not a single shared test account for every VU, which would accidentally load-test one hot cache row instead of the real system.

Question 36

How do you design a spike test?

Accepted Answer

A spike test applies an abrupt jump in load — no gradual ramp — from a baseline to a much higher level within seconds, holds it briefly, then drops back down, specifically to test the system's elasticity and recovery rather than its steady-state capacity. Design it as: baseline load, an instant jump to spike level, a short hold, an instant drop back to baseline, and then an extended observation window.

Example k6 stages: `{duration:'5m', target:200}, {duration:'30s', target:5000}, {duration:'5m', target:5000}, {duration:'30s', target:200}, {duration:'15m', target:200}`. The key thing to check in that final stage isn't just whether the spike itself caused errors, but whether latency and resource usage fully return to baseline afterward — or whether the spike left something in a degraded state, like a leaked connection pool, a cache that never repopulated correctly, or autoscaled pods that never scale back down.

Question 37

What's the difference between vertical and horizontal scaling from a performance testing perspective?

Accepted Answer

Vertical scaling (scale-up) gives a single node more resources — bigger CPU, more RAM, faster disk. Performance testing it means re-running the same test against the bigger hardware and checking whether throughput improves proportionally, which it often doesn't past a point, because a single-threaded bottleneck or lock contention can't be fixed by adding more cores. Horizontal scaling (scale-out) adds more nodes behind a load balancer; performance testing it means checking whether throughput scales near-linearly as nodes are added, or whether a shared resource — a database, cache, or session store — caps the gains regardless of node count.

For example, doubling a single app server's CPU from 4 to 8 cores might only improve throughput by 20%, because the app is I/O-bound waiting on a database rather than CPU-bound — while adding a second app server doubles throughput because the bottleneck genuinely was app-server capacity. Testing both approaches empirically, rather than assuming, is how you avoid over-provisioning the wrong tier.

Question 38

What is the coordinated omission problem in load testing tools, and why does it make reported percentiles misleading?

Accepted Answer

Coordinated omission happens when a load-testing tool's request scheduling accidentally 'cooperates' with the very slowdown it's supposed to measure. In a closed-loop tool, a worker thread sends a request, waits for the response, then immediately sends the next one — so if a single response stalls for, say, 5 seconds, that thread simply sends far fewer requests during the stall. The requests that would have been sent during that window are never sent and never recorded, meaning the massive latency spike real users would have experienced gets averaged away instead of counted at its true magnitude — systematically understating tail latency exactly when it matters most.

The fix is using tools or execution modes that schedule requests at fixed intervals regardless of prior response completion (an open workload model) and record the intended send time against the actual completion time — this is why Gil Tene's HdrHistogram-based tooling, and open-model executors like k6's constant-arrival-rate, exist. Instead of a stalled worker quietly skipping requests it couldn't get to, an open-model tool issues N iterations per second on schedule and reports exactly how delayed the responses actually were, so a rare 5-second stall shows up in p99.9 rather than vanishing.

Question 39

How does the Universal Scalability Law differ from Amdahl's Law in modeling system scalability?

Accepted Answer

Amdahl's Law models scalability limits purely from serialization: speedup is capped by the fraction of work that must run sequentially, and adding more processors or threads makes speedup approach — but never exceed — 1/(serial fraction). Critically, it never predicts throughput getting worse as concurrency increases. The Universal Scalability Law (Gunther) adds a second term for coherency/crosstalk — the cost systems pay to keep shared state consistent across nodes or threads, such as cache invalidation, lock contention, or data synchronization — which means USL correctly predicts that beyond some concurrency level, throughput doesn't just plateau, it actually declines, something Amdahl's Law structurally cannot express.

For example, adding more app-server replicas that all write to one Redis instance for session coherency initially scales throughput, but past a point the coordination overhead — cache-invalidation chatter between nodes — grows faster than useful work, and total throughput drops. You can fit your own load-test throughput-vs-concurrency data points to the USL formula (alpha for the contention coefficient, beta for the coherency coefficient) to predict exactly where that peak or decline point sits before ever provisioning that many nodes for real.

Question 40

How does JVM warm-up and JIT compilation affect performance test results, and how do you control for it?

Accepted Answer

The JVM starts by executing bytecode through the slow interpreter, and the JIT compiler only compiles hot methods to optimized native code after they've been invoked enough times to cross tiered-compilation thresholds — so the first minutes of any JVM-based service under load will show artificially slow, unstable response times that have nothing to do with the code's real steady-state performance, purely because the JIT hasn't kicked in yet, plus class-loading and initial GC generation sizing add further one-time overhead.

To control for it, include an explicit warm-up phase in the load test — run representative traffic for several minutes before recording results, which most tools support (k6 stages excluded from thresholds, JMeter's startup delay) — and discard that warm-up window's data from your reported percentiles entirely, rather than blending it into steady-state numbers, since including it makes p99 look far worse than what real sustained traffic will actually experience.

Question 41

What is the 'noisy neighbor' problem in cloud/virtualized load testing infrastructure, and how do you mitigate it?

Accepted Answer

In multi-tenant virtualized infrastructure, other tenants' workloads sharing the same physical host can silently consume shared resources — CPU steal time on the hypervisor, shared network bandwidth, shared disk I/O on a SAN — that your instance can't see or control, causing your load test results to vary run-to-run for reasons unrelated to your own application. A noisy neighbor spiking CPU on the same physical box can add real latency to your test that will never reproduce on a different run or a different machine.

Mitigate it by monitoring hypervisor-level metrics your cloud provider exposes — for example, AWS CPU steal time in top or CloudWatch — or by using dedicated/bare-metal instance types that remove sharing entirely. Also run each test multiple times and check for anomalous outlier runs rather than trusting a single result, and where budget allows, use dedicated hosts or guaranteed (not burstable/shared) resources for your load generator and system under test during critical benchmark runs.

Question 42

How does TCP slow start affect performance tests involving many short-lived connections?

Accepted Answer

Every new TCP connection starts with a small congestion window and ramps it up gradually as ACKs confirm data delivery. For a long-lived connection transferring lots of data, this overhead is negligible — but for workloads with many short-lived connections, where each request opens a fresh connection, sends a small payload, and closes, a large fraction of every single request's time is spent inside slow start's initial low-throughput window, never reaching full link speed before the connection ends. The measured latency ends up reflecting TCP handshake and ramp-up cost more than actual application processing time.

To diagnose and fix it, enable and correctly configure HTTP keep-alive/connection reuse in both your load-testing tool and the application server so connections are reused across many requests, amortizing slow start's cost across the connection's lifetime instead of paying it on every single request. Where TLS is involved, session resumption via TLS session tickets similarly avoids repeating the expensive full handshake per connection.

Question 43

What is tail latency amplification in fan-out architectures, and how do you test for it?

Accepted Answer

In a service that fans out one incoming request into calls to multiple downstream services and waits for all of them before responding, the overall response time is gated by the slowest of those parallel calls, not the average. So if each downstream service independently has a 1% chance of a slow response, a request that fans out to 20 downstream calls has roughly an 18% chance (1 minus 0.99 to the 20th power) that at least one of them is slow — meaning nearly a fifth of aggregating requests get amplified to the tail latency of a single slow dependency, even though each dependency individually looks fine at its own p99.

Test for it by load testing the actual fan-out endpoint, not just each downstream service in isolation, and comparing the aggregator's p99 against each dependency's own p99. A mitigation worth testing alongside this is hedged requests — firing a duplicate request to a backup replica if the primary hasn't responded within some threshold and taking whichever returns first — which trades a bit of extra load for a meaningfully lower amplified tail.

Question 44

How does container CPU throttling (cgroups CFS quota) cause performance test results to look worse than the actual hardware allows?

Accepted Answer

When a container has a CPU limit set — e.g., Kubernetes resources.limits.cpu: '1' — the kernel's CFS bandwidth controller enforces it by allotting a CPU quota per fixed period (default 100ms). If the process bursts and consumes its entire quota within, say, the first 20ms of that period, the kernel throttles it — stops scheduling it — for the remaining 80ms of that period, even though the node's actual physical CPU may be sitting completely idle. The application appears to 'pause' repeatedly under load in a way that has nothing to do with real hardware saturation, only with the quota/period math.

Diagnose it via container_cpu_cfs_throttled_periods_total / container_cpu_cfs_throttled_seconds_total (cAdvisor/Prometheus metrics) — a high throttled-periods ratio while node CPU utilization looks moderate is the signature. Fix by raising the CPU limit, removing hard limits in favor of requests-only where the platform allows, or, for latency-sensitive JVM workloads, using fewer, larger containers instead of many small CPU-limited ones so the quota period doesn't clip legitimate short bursts.

Question 45

What is the thundering herd problem, and how would you performance test a system's resilience to it?

Accepted Answer

Thundering herd is when a large number of clients, threads, or processes all wake up and act simultaneously in response to the same trigger — for example, a popular cache key expiring, causing every concurrent request for that key to miss cache and hammer the database at once, or every client's fixed-interval retry firing at the exact same moment after an outage, re-creating the overload that just caused the outage.

To performance-test resilience against it, deliberately force the herd: expire a hot cache key under sustained concurrent load and watch for a database query spike, or kill and restart a dependency mid-test and check whether all clients' retries synchronize into a new spike on recovery. Mitigations to verify are actually implemented and effective under this test are request coalescing or single-flight, where only one request actually goes to the database on a cache miss while others wait for that result, and jittered exponential backoff instead of fixed-interval retries.

Question 46

How do you use HdrHistogram for accurately recording latency distributions in a load test?

Accepted Answer

HdrHistogram (High Dynamic Range Histogram) records latency values with constant, configurable relative precision across a huge value range — from microseconds to hours — using fixed memory, instead of naive approaches like storing every sample, which is memory-unbounded, or fixed linear buckets, which lose precision at either the low or high end. This matters for load testing specifically because accurately capturing rare, extreme tail values — a 1-in-a-million 30-second stall next to a sea of 5ms responses — is exactly what naive sampling or coarse bucketing tends to lose.

Example usage in Java:
```java
Histogram hist = new Histogram(3600000000L, 3); // up to 1 hour, 3 significant figures
hist.recordValue(responseTimeMicros);
System.out.println(hist.getValueAtPercentile(99.9));
```
Most modern load testing tools — Gatling, wrk2, JMeter with a plugin — use HdrHistogram internally precisely so their reported p99/p99.9 numbers are trustworthy rather than being an artifact of how samples happened to get bucketed.

Question 47

What is backpressure and load shedding, and how do you validate they work correctly under a stress test?

Accepted Answer

Backpressure is a downstream component signaling upstream to slow down — rather than silently queueing infinitely or crashing — such as a bounded queue that blocks or rejects producers once full, or an HTTP 429 response with a Retry-After header. Load shedding is a system proactively dropping or rejecting a portion of incoming requests once it detects it's overloaded, specifically to protect its ability to serve the requests it does accept, rather than degrading uniformly until everything times out.

To validate both under a stress test, push load well past capacity and confirm the system returns fast, explicit rejections — 429 or 503 — for the excess portion instead of accepting everything and letting all requests slowly time out. Then confirm the requests that are accepted keep meeting their latency SLA even while overloaded, proving shedding is protecting good traffic rather than failing randomly. A system with backpressure done right shows a flat accepted-throughput ceiling with a rising reject rate above it, rather than latency degrading uniformly across all requests as load increases.

Question 48

How do JVM garbage collector safepoint pauses show up in performance test results, and how do you diagnose them?

Accepted Answer

A JVM safepoint is a point where all application threads are stopped so the JVM can safely perform an operation requiring a consistent view of memory — most commonly garbage collection, but also things like biased-lock revocation, class redefinition, or deoptimization. Stop-the-world GC pauses are the most visible example, but any safepoint operation pauses every thread, even ones unrelated to what triggered it — and a thread that's slow to reach a safepoint, one stuck in a long-running loop without a safepoint poll, can delay the entire JVM's pause, not just its own.

In performance test results, these show up as brief, periodic latency spikes across unrelated requests happening at the same instant, not correlated with any specific endpoint's logic — visible via the -Xlog:safepoint or -XX:+PrintGCApplicationStoppedTime JVM flags, which report total time application threads were stopped. Diagnose by correlating GC logs' pause timestamps directly against your load test's latency spike timestamps — if they line up exactly, it's confirmed GC/safepoint-caused rather than an application code issue, and the fix path is tuning the GC algorithm or heap sizing, such as moving to G1 or ZGC for lower pause targets, rather than chasing application code.

Question 49

What is differential/canary performance testing, and how does it differ from a standard load test?

Accepted Answer

A standard load test runs a fixed test plan against one version of the system and evaluates it against absolute thresholds. Differential/canary performance testing instead runs the same load test simultaneously, or back-to-back under identical conditions, against two versions — the current production baseline and a new candidate build — and compares their metrics directly against each other. This is more sensitive to regressions because it doesn't rely on a possibly-stale absolute threshold; a 15% latency regression between build N and N+1 gets caught even if both builds are technically still under the SLA.

For example, route 5% of production traffic to a canary deployment of the new release, run identical synthetic load against both the canary and a same-sized baseline pool for 30 minutes, and automatically fail the rollout if the canary's p95 or error rate is statistically worse than the baseline's. This is how progressive-delivery pipelines — using tools like Kayenta or Argo Rollouts analysis — gate deployments on live performance comparison rather than a fixed number decided months earlier.

Question 50

How does HTTP keep-alive/connection reuse configuration in your load testing tool affect the validity of your results?

Accepted Answer

If your load-testing tool defaults to closing and reopening a new TCP (and TLS) connection for every single request — because keep-alive isn't enabled, a Connection: close header is being sent, or the tool's connection pool is undersized relative to VU count — you end up measuring the cost of handshakes (TCP SYN/ACK, TLS negotiation) as if it were application response time, producing latency numbers far worse than what real users experience, since browsers and most real clients reuse connections aggressively.

Conversely, keeping every connection alive can also hide a real issue if your production traffic pattern genuinely churns connections — for example, many distinct client IPs each making one request, like disparate mobile users. The fix is matching the tool's connection-reuse setting to your actual traffic model rather than blindly maximizing reuse: in JMeter, check the HTTP Request Defaults 'Use KeepAlive' setting; in k6, http.get reuses connections per VU by default via a connection pool, which is usually the right model for logged-in-session traffic but wrong for simulating many one-off anonymous visitors.

Performance Testing Interview Questions & Answers

Ready to practice these live?