Lesson 01 · Performance Testing

Beyond the 1Z0-830 exam

Performance testing answers "is it fast enough, under realistic load?" — a different question from "is it correct?". You measure latency and throughput under controlled load with tools like JMeter and Gatling, and you read the results as percentiles, not averages.

Objectives

After this lesson you will be able to:

• Distinguish load, stress, soak, and spike testing.
• Name the key metrics: throughput, latency, error rate.
• Explain why percentiles (p95/p99) beat the average.
• Sketch a JMeter/Gatling test and set a latency SLO.

Kinds of performance test

Type	Question it answers
Load	Does it meet its targets at expected/peak traffic?
Stress	Where does it break, and how does it fail? (push past the limit)
Soak (endurance)	Does it degrade over hours? (memory leaks, resource exhaustion)
Spike	Can it absorb a sudden surge and recover?

The metrics that matter

• Throughput — requests/second the system sustains.
• Latency (response time) — how long each request takes. Report the distribution.
• Error rate — % of failed requests under load (often the first sign of saturation).
• Concurrency — number of simultaneous virtual users.

Percentiles, not averages

The central lesson — and what the lab proves. Imagine 99 requests at 10 ms and one at 5000 ms:

mean  ≈ 60 ms      ← the average looks fine
p50   = 10 ms      ← half are this fast
p99   = 10 ms      ← 99% are this fast
max   = 5000 ms    ← but someone waited 5 seconds

The average hides the outlier; the tail (p95/p99/max) is what real users feel. So SLOs are written on percentiles: "p99 latency under 200 ms". The lab's LatencyStats computes these and a meetsSlo(99, 200) check:

LatencyStats stats = new LatencyStats(samples);
assertThat(stats.meetsSlo(99, 200)).isTrue();   // p99 within the 200ms budget

Trap — averaging away the tail

A dashboard showing only mean response time can be green while a meaningful slice of users has a terrible experience. Always look at p95/p99 and max, and at the error rate under load — not just the average.

A Gatling sketch

Gatling tests are code (a Scala/Java DSL), which fits version control and CI well:

setUp(
  scenario("Browse widgets")
    .exec(http("list").get("/widgets").check(status().is(200)))
    .injectOpen(rampUsers(500).during(Duration.ofSeconds(60)))   // ramp to 500 users
).assertions(
  global().responseTime().percentile(99).lt(200),                // p99 < 200ms
  global().failedRequests().percent().lt(1.0)                    // < 1% errors
);

JMeter covers the same ground with a GUI for building plans (run headless in CI). Both generate reports with the percentile breakdowns above.

Gotcha — measure a warmed-up JVM

The JVM JIT-compiles hot code only after it's run enough (Module 12). Numbers from the first few seconds reflect cold, interpreted code, not steady state. Include a warm-up ramp and discard it, or your results will look artificially slow.

SDET note

Make performance a gate, not a one-off: assert SLOs in the test (as the Gatling snippet does) so a regression fails the build in CI (Module 20), instead of being noticed in production. The lab's meetsSlo is that idea in miniature.

Key Takeaways

• Load verifies expected/peak; stress finds the breaking point; soak finds slow degradation; spike tests surges.
• Track throughput, latency, error rate, concurrency.
• Report percentiles (p95/p99) and max, not the average — the tail is what users feel.
• Write SLOs on percentiles and assert them so regressions fail the build.
• Warm up the JVM before measuring; watch the error rate as the first sign of saturation.

Lesson Quiz

Lesson Quiz · Performance Testing0 / 5

1. Load testing vs stress testing:

   • AIdentical
   • BLoad verifies behavior at expected/peak traffic; stress pushes past limits to find the breaking point
   • CStress is gentler than load
   • DLoad tests security

2. Why prefer p99 over the mean for latency?

   • Ap99 is easier to compute
   • BA few slow requests barely affect the mean but define the tail users actually experience
   • CThe mean is always wrong
   • Dp99 is always smaller

3. Given 99 requests at 10ms and one at 5000ms, the p50 is about…

   • A5000ms
   • B10ms
   • C60ms
   • D2505ms

4. Why warm up the JVM before measuring performance?

   • ATo use more memory
   • BJIT compilation kicks in after code runs enough; cold/interpreted numbers aren't steady state
   • CTo avoid garbage collection forever
   • DIt's a JMeter requirement only

5. A good way to prevent performance regressions is…

   • ARun a load test manually once a year
   • BAssert SLOs (e.g. p99 < 200ms, errors < 1%) in the test so a regression fails the CI build
   • COnly watch the mean
   • DDisable warm-up

---

Next: Security Testing. This module's lab is in labs/src/main/java/com/jse21/m19_specialized/.