Academy

In JMeter: add a Thread Group (1 user, 1 loop), add an HTTP Request sampler pointing at your endpoint, add a View Results Tree listener, and press Run. In k6: write `export default function() { http.get('https://your-endpoint'); }` and run `k6 run script.js`. The response time in the results table is your first latency measurement.

Set the Thread Group to 1 user, loop count = forever, duration = 5 minutes. Add a Summary Report or Aggregate Report listener. After the run, screenshot or export the table showing min, average, p90, p95, and max columns. The gap between average and p95 is your variance fingerprint for this endpoint at zero concurrency.

In JMeter: add a Gaussian Random Timer (deviation 1000ms, constant delay 2000ms) inside your Thread Group after each sampler. Run once without it, note throughput. Add it and re-run. In k6: add `sleep(3)` at the end of your default function. A realistic think time of 2-5 seconds typically reduces throughput by 60-80% compared to a zero-think-time run - that reduction reflects reality, not a regression.

In JMeter: add a Response Assertion to your sampler. Check 'Response Code' equals 200, and 'Response Body' contains a known string (e.g. a JSON key or page title). To see it fail: change the expected string to 'INTENTIONAL_FAIL' and re-run. The error % will jump to 100% and View Results Tree will show red. In k6: use `check(res, { 'status 200': (r) => r.status === 200, 'body has key': (r) => r.body.includes('expected') })` and add a threshold to fail the test.

Run 10 minutes at 10-20 users. In JMeter's Aggregate Report: note that p90 and p99 diverge from the mean as load grows - this is the 'long tail'. Standard deviation above 20% of the mean signals instability. Throughput (req/s) is your server's sustained capacity at that concurrency. The single metric to show a developer is p95: it represents the worst experience 1 in 20 real users encounters.

Create data.csv with a 'searchTerm' column and 10+ unique values. In JMeter: add a CSV Data Set Config element pointing to the file, set variable name to 'searchTerm', recycle = true. Reference it in your HTTP Request as a parameter value: `${searchTerm}`. In k6: use `const data = new SharedArray('terms', () => JSON.parse(open('./data.json')))` and index with `data[exec.scenario.iterationInTest % data.length]`. Verify uniqueness by checking the access logs on your server.

In JMeter: set Thread Group to 50 users, ramp-up period = 500 seconds (1 user added per 10s), loop = forever, duration = 600s. Use a Response Time Graph listener to watch the curve in real time. The 'knee' appears where the slope steepens - typically when threads waiting for a response exceed the server's worker pool size. Note the user count at that inflection point and correlate with server CPU or thread pool metrics.

Set Thread Group to 20 users, ramp-up = 30s, loop = forever, scheduler duration = 900s (15 min). Add a Response Time Graph with a granularity of 60000ms (1 min) to see per-minute averages. Upward creep is the signature of a slow memory leak, connection pool not returning connections, or a cache filling up. Flat with occasional spikes points to GC pauses. Flat throughout = healthy baseline.

Use three Thread Groups in sequence: (1) 5 users for 2 min as baseline, (2) 100 users, ramp-up 0s, duration 2 min for the spike, (3) 0 users (or 1) for 2 min cooldown. In k6 use stages: `{ duration: '2m', target: 5 }, { duration: '0s', target: 100 }, { duration: '2m', target: 100 }, { duration: '0s', target: 0 }, { duration: '2m', target: 0 }`. Watch for 503s or timeouts during the instant jump - these reveal the absence of request queuing or circuit breaking.

Set Thread Group to 15 users, ramp-up = 60s, scheduler duration = 7200s (2 hrs). Capture a server-side memory snapshot at t=0, t=30min, t=60min, t=120min. In JMeter use the Backend Listener with InfluxDB + Grafana for live trending, or simply export Aggregate Report CSVs at each checkpoint. A healthy system holds flat memory; a leaking one climbs steadily. GC frequency increase with no corresponding memory drop is the classic JVM leak signature.

Use JMeter's Ultimate Thread Group plugin or five sequential Thread Groups each with a different user count and 5-minute duration. Record throughput from the Aggregate Report at each step. In k6: use stages with `{ duration: '5m', target: 10 }` increments. Plot users vs throughput in a spreadsheet. The step where throughput stops increasing (or drops) while users rise is saturation. Little's Law: throughput = concurrency / response time - when response time climbs faster than concurrency, throughput plateaus.

Script A: 50 Thread Group users with 3s think time - this is concurrency-based, throughput is emergent. Script B: use JMeter's Constant Throughput Timer set to 600 requests/min (10/s), or k6's `scenarios: { constant_arrival_rate: { rate: 10, timeUnit: '1s', preAllocatedVUs: 20 } }`. Script A models 'users browsing'; Script B models 'transactions per second from a queue'. Most real-world web systems are better modeled with arrival-rate - it catches cases where the system can't keep up with demand regardless of user count.

In JMeter: add a Regular Expression Extractor (or JSON Extractor) post-processor to the first request. Set the reference name to 'token', the expression to match the dynamic value (e.g. `"token":"(.+?)"` for a JSON response). Reference it downstream as `${token}`. To confirm correlation works: add a Debug Sampler after the extractor and inspect the variable value in View Results Tree. If the variable shows 'FAILED' the regex did not match - adjust the expression.

In JMeter: add an HTTP Cookie Manager and HTTP Header Manager at Thread Group level (not test plan level - this scopes them per virtual user). Use a CSV Data Set Config with username/password columns, 'Sharing mode = Current thread' to ensure each VU reads its own row. Each VU logs in, gets its own session cookie, performs actions, then logs out. In k6: create a cookieJar per VU with `http.cookieJar()` and pass it in request params. Verify isolation by asserting each response contains the correct username.

Generate a realistic dataset: export production search terms, user IDs, or product SKUs from your analytics tool (anonymized). In JMeter: CSV Data Set Config with 'Recycle on EOF = false' and 'Stop thread on EOF = true' if you want each row used exactly once, or 'Recycle = true' for continuous cycling. Set 'Sharing mode = All threads' only if the data is read-only. For 1000+ rows the file must be on the load injector's disk - not a network path. In k6 use SharedArray to load the file once across all VUs.

In JMeter: add a Constant Throughput Timer set to 600 samples/min, mode 'All active threads (shared)'. The timer will add delay to keep the aggregate rate at target. If the system can't sustain the rate, the timer has no effect and throughput lags - this gap is the capacity ceiling. In k6: use `scenarios.constant_arrival_rate` with `rate: 10, timeUnit: '1s'`. Watch 'dropped_iterations' in the k6 output - any non-zero value means the system could not fulfill the target rate.

In JMeter: create three Thread Groups with user counts proportional to your mix (e.g. 70, 20, 10 users if running 100 total). Wrap each flow in a Transaction Controller so the Aggregate Report shows per-journey metrics. Alternatively use a single Thread Group with a Random Controller or Throughput Controller to route iterations by ratio. In k6: define separate scenarios with `weight` in the executor config, or use `exec` to call different functions. Check per-transaction p95 in the results - write-heavy transactions (checkout) almost always suffer first under blended load.

In JMeter distributed mode: start jmeter-server on each remote injector machine, then run the controller with `-R injector1,injector2 -n -t test.jmx -l results.jtl`. Each injector runs all threads in the plan - so set each Thread Group to total_users / num_injectors. Monitor injector CPU with top or Task Manager; if any injector exceeds 80% CPU it is the bottleneck, not the app. In k6 Cloud or k6 OSS with multiple instances: aggregate results with a shared output target (InfluxDB or Prometheus remote write).

Ramp users past the pool size (e.g. if the DB pool is 20, ramp to 30-40 users). The signature: response time climbs sharply while CPU stays flat - threads are idle, waiting for a free connection. In JMeter check the Active Threads chart vs Response Time chart - they diverge at the pool limit. To confirm: look at your DB or app server connection pool metrics (HikariCP exposes 'pool.wait' via JMX/Prometheus). Fix by increasing pool size or reducing per-request hold time, not by adding more app servers.

Run a heap-intensive workload for 20+ minutes. Enable GC logging on the JVM: `-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=20m`. Use GCViewer or GCEasy to parse the log post-test. In JMeter's Response Time Graph, GC pauses appear as periodic vertical spikes with fast return to baseline - this is stop-the-world. Sustained GC that never drops back suggests the heap is undersized. Correlate the spike timestamps in gc.log against your JMeter results timestamps to confirm the relationship.

Run a step-load test (every 5 min add 10 users) while watching `top` or a Prometheus CPU dashboard. When CPU crosses ~90%, note the user count. Keep adding users: throughput will plateau then fall as the OS spends more time on context switching than actual work. The run queue (`vmstat` column 'r' on Linux) exceeding logical CPU count is the technical definition of saturation. This user count minus 10-20% is your safe operating ceiling for a CPU-bound workload.

Run a DB-heavy endpoint under load. Enable slow query log: in MySQL `SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5;`. In PostgreSQL use `log_min_duration_statement = 500`. After the test, run `EXPLAIN ANALYZE` on the worst offenders. A full table scan (Seq Scan with high row count in Postgres, or 'type: ALL' in MySQL EXPLAIN) without an index is the most common culprit. Add the missing index and retest - throughput typically doubles or more for read-heavy workloads.

Run 1: Flush the cache (Redis FLUSHDB or app restart), then run 100 unique-URL requests. Capture p95. Run 2: Repeat the exact same 100 URLs in the same order. Capture p95 - this is the warm-cache baseline, often 5-50x faster. Run 3: Mid-test, flush the cache with a script or CLI command. Watch the Response Time Graph for the cliff. To instrument cache hits: add a custom response header in your app (e.g. X-Cache: HIT/MISS) and use a JMeter Response Assertion or extractor to count the ratio.

On Linux use `tc` to add artificial latency: `sudo tc qdisc add dev eth0 root netem delay 100ms`. On Windows use Clumsy or Windows Traffic Shaping. Run the same script with 0ms, 100ms, 500ms added RTT. Throughput drops approximately as: T = concurrency / (base_latency + added_latency). Remove latency with `sudo tc qdisc del dev eth0 root`. The key insight: adding 100ms to a 50ms response doubles end-to-end time and halves throughput for a fixed-concurrency model - but for arrival-rate models, the system simply can't keep up and starts queuing.

In k6: add thresholds to the script - `thresholds: { 'http_req_duration{p95}': ['p(95)<500'], 'http_req_failed': ['rate<0.01'] }`. k6 exits with code 99 on threshold breach, which fails a CI step. In JMeter: run headless with `-n -t test.jmx -l results.jtl` and use the JMeter CI plugin or a post-step script that parses the JTL and exits non-zero if p95 exceeds your SLO. Set your threshold at 120% of your Day 2 baseline p95 - tight enough to catch regressions, loose enough to avoid false positives from environment noise.

Open Datadog, Grafana, New Relic, or your APM of choice in one window. Start the load test. When JMeter or k6 shows a latency spike, immediately look for the matching spike in: (1) CPU - compute-bound, (2) DB query time - database-bound, (3) GC pause duration - memory-bound, (4) downstream service latency - dependency-bound. The most useful APM feature for this is a distributed trace waterfall: it shows exactly which span is consuming the most wall-clock time within a single slow request.

Run a steady-state load at 60% of capacity. In a second terminal: kill a pod (`kubectl delete pod <name>`), block a port (`sudo iptables -A INPUT -p tcp --dport 8080 -j DROP`), or pause a container (`docker pause <id>`). Watch the JMeter error rate spike. A well-architected system shows: a brief error spike (< 5s), automatic failover or retry, then error rate returns to near-zero. Catastrophic failure is when the error rate stays high until manual intervention. Restore with `kubectl rollout restart` or `docker unpause`. Document the mean time to recover (MTTR).

From your Day 11 step-load data you have throughput at each user count. From Day 21 you have the saturation point. Apply Little's Law: N = X * R, where N = concurrent users, X = throughput (req/s), R = mean response time (s). Solve for X_max at your observed saturation. Headroom % = (X_max - X_current) / X_max. If current production throughput is 80% of X_max, you have 20% headroom. The resource that hits its limit first (CPU, DB connections, memory) at X_max is your first failure point under a traffic doubling.

Structure your one-pager: (1) What was tested - endpoint, duration, user count, tool. (2) What was found - the single worst metric with a before/after comparison. (3) The bottleneck - one sentence, no jargon (e.g. 'The checkout page slows to 4 seconds at 200 users because the database query is missing an index'). (4) The impact - at current growth, this limit will be hit in N weeks based on traffic trend. (5) The recommendation - one concrete action with an estimated effort. Attach a screenshot of the relevant graph. The report should be readable in under 2 minutes.

The diagnostic sequence: (1) Run a 1-user baseline to confirm the endpoint is functional (Day 2). (2) Ramp to find the knee (Day 7). (3) Check if it is CPU, memory, DB, or I/O bound using the bottleneck toolkit from Days 19-24. (4) Correlate with APM traces (Day 26). (5) Document the root cause with evidence: a slow query log line, a GC log excerpt, or a connection pool wait histogram. (6) Propose a fix, estimate its impact on the saturation point, and commit the test library so the next engineer has a starting point. This sequence is repeatable on any system.