Checkpoint Lab — Load Generator Sizing, JVM Tuning, OS Limits, and Network Capacity

1. Exact assumptions and ceilings

2. Preflight inventory

Record before either run:

• CPU model/physical/logical cores, RAM, disk free space, NIC/link state;
• JMeter 5.6.3 and exact Java 17 build;
• effective VM.flags/heap/GC after JMeter starts;
• Windows dynamic TCP port ranges or Linux ip_local_port_range;
• Windows handle/process state or Linux ulimit -n/fs.file-max;
• DNS cache/resolver snapshot even though benchmark uses IP;
• hash/diff proving the two JMXs differ only in KeepAlive.

3. Predictions before execution

P1 — workload: both variants produce exactly 1,000 successful JTL rows and 1,000 target events.

P2 — sockets: connection-close baseline uses a high fraction of unique client ports; keep-alive run uses dramatically fewer unique ports/connections and less TIME_WAIT growth.

P3 — target: target service_wall_ms remains approximately unchanged because target code/payload/workload are identical.

P4 — generator: keep-alive may reduce connect/CPU overhead and improve or stabilize achieved RPS, but the exact percentage is machine-dependent and must be measured.

P5 — heap/JTL: neither variant should require materially different heap live-set or JTL bytes/sample; if they do, investigate another confounder.

4. Run the connection-churn baseline

curl.exe --fail --silent -X POST `
  "http://127.0.0.1:8026/reset?run_id=p26-check-close"

& "$env:JMETER_HOME\bin\jmeter.bat" `
  -n -t .\plans\generator-close.jmx `
  -q .\config\generator-local.properties `
  -Jrun.id=p26-check-close `
  -l .\results\p26-check-close\results.jtl `
  -j .\results\p26-check-close\jmeter.log

Capture the platform/JVM inspections from Lesson 2 during the run and immediately after. Save the outputs under the run directory.

5. Baseline verification gate

python tools/profile_analyzer.py results/p26-check-close/results.jtl
python tools/analyze_target.py results/server-events.jsonl p26-check-close

Require 1,000 rows/events, zero failures, stable target service time. Record unique-client-port count, socket states, CPU/heap/GC, NIC counters and JTL file bytes.

6. Identify the dominant observed generator pressure

Use evidence, not the expected answer. The intended baseline should show connection/local-port churn while target service time remains stable. But if CPU or GC is clearly the first limiting signal on your machine, record that instead and explain why the keep-alive experiment may not address the dominant constraint.

Do not manufacture a “port exhaustion” conclusion merely because the lesson demonstrates connection churn.

7. Reversible change and rollback record

Change only:

HTTP Request — Work
Use KeepAlive:
  BEFORE = unchecked
  AFTER  = checked

Rollback:
  reopen generator-close.jmx, or uncheck Use KeepAlive in the copied plan.

No HEAP, GC, OS, DNS, firewall, antivirus, timeout, retry, thread, loop, pacing, payload, target or JTL setting changes.

8. Run the corrected profile identically

curl.exe --fail --silent -X POST `
  "http://127.0.0.1:8026/reset?run_id=p26-check-keepalive"

& "$env:JMETER_HOME\bin\jmeter.bat" `
  -n -t .\plans\generator-keepalive.jmx `
  -q .\config\generator-local.properties `
  -Jrun.id=p26-check-keepalive `
  -l .\results\p26-check-keepalive\results.jtl `
  -j .\results\p26-check-keepalive\jmeter.log

Capture exactly the same process/JVM/socket/NIC/JTL measurements at comparable points.

9. Before/after comparison

python tools/compare_profiles.py   results/p26-check-close/results.jtl   results/p26-check-keepalive/results.jtl

python tools/analyze_target.py results/server-events.jsonl p26-check-close
python tools/analyze_target.py results/server-events.jsonl p26-check-keepalive

10. Decide whether usable capacity improved

Use this wording discipline:

• If keep-alive maintains the same 1,000 samples with dramatically lower connection/TIME_WAIT pressure and equal/better CPU/RPS, state that generator headroom improved for this workload.
• If achieved RPS materially improves while target service time and all workload inputs stay stable, state the measured improvement.
• If RPS is unchanged, do not claim a higher maximum. State that the plan reduced socket pressure but the checkpoint did not reach either variant's sustainable-load ceiling.
• If another resource (CPU/GC/disk) dominates, state that keep-alive was not the limiting fix and identify the next evidence-backed experiment.

11. Optional safe capacity step

Only if both 1,000-sample runs are valid and you need evidence of additional usable capacity, perform one small step such as 12 threads ×100 loops (1,200 samples) with keep-alive enabled. Keep the target/monitoring identical and abort on the same resource gates. This optional step is not required to complete the chapter and should not be run if the baseline already showed generator pressure.

12. Required evidence packet

13. Example validity statement

14. Verification checklist

• Only 127.0.0.1:8026.
• JMeter 5.6.3 / Java 17 / no plugins.
• Same threads/loops/pacing/payload/target/result schema.
• Only KeepAlive differs.
• 1,000 JTL +1,000 target events each; zero failures.
• Heap/GC + CPU + handles/FDs + socket states recorded.
• Dynamic-port range inspected, not changed.
• DNS/NIC/JTL size/RPS captured.
• Target service time stable enough for comparison.
• Conclusion distinguishes improved headroom from unmeasured maximum capacity.

15. Cleanup / rollback

1. Stop JMeter and the localhost fixture after evidence capture.
2. Keep close/keepalive JTL, matching jmeter.log, profile outputs and target JSONL until review.
3. Rollback is simply the original generator-close.jmx; no OS/JVM global tuning was changed.
4. Delete disposable artifacts only after the retention decision.
5. No production/public target, real credential, firewall/antivirus state, RMI service, managed cloud, paid CI, OS port/FD/DNS setting or system-wide JVM security setting was modified.

16. What Chapter 26 adds to the operating model

The production performance-testing operating model now has a load-generator capacity contract: hardware/JVM inventory, effective heap/GC flags, measured heap/GC/CPU, socket/handle/FD/local-port state, DNS strategy, NIC/disk/JTL cost, HTTP connection/retry policy, configured-versus-achieved load, target service control, per-engine headroom criteria, before/after tuning evidence and rollback are required before an injector's workload is considered trustworthy.

Chapter 27 moves to Containers, Kubernetes, Ephemeral Injectors, and Infrastructure Automation. It carries this capacity contract into container CPU/memory quotas, cgroups, ephemeral filesystems, pod/service DNS, virtual networking, image/version pinning and reproducible disposable generator fleets.

Knowledge check

Official references and version notes

• Apache JMeter downloads — current stable release and Java requirement.
• Apache JMeter current changes — Java guidance for the 5.6.x line.
• JMeter Getting Started — load-generator sizing, CLI guidance, default heap/GC launcher settings and JVM environment variables.
• JMeter Best Practices — effective thread count, CLI execution, listener/result minimization, CSV output and generator resource reduction.
• Component Reference — HTTP Request — HttpClient4 default, keep-alive behavior and response-body MD5 option.
• Component Reference — DNS Cache Manager — JVM DNS cache behavior and HttpClient4-only per-thread DNS control.
• JMeter Properties Reference — HttpClient4 retry, connection TTL/validation and result-save properties.
• JDK 17 jcmd — JVM process/heap inspection.
• JDK 17 jstat — GC/heap utilization statistics; documented as experimental/unsupported.