Chapter 22Lesson 05~260 minutes

Checkpoint Lab — Listeners, Result Collection, Memory Cost, and Safe Debugging

The checkpoint removes the biggest confounder from Lesson 2: both variants now execute the same 10 target requests. The heavy variant uses GUI View Results Tree plus XML response/header/sampler retention in a strictly tiny run; the lean variant uses CLI metadata-only CSV. You will predict the result/generator/privacy differences, verify target workload equivalence, and define what each project phase is allowed to retain.

Checkpoint10 vs 10 samplesHeavy XMLLean CSVRetention policy

Learning objectives

Run identical 1-thread ×10-loop target workload under heavy and lean result policies.
Quantify JTL file size, response-data nodes, fake privacy markers and generator heap/CPU.
Verify both variants produce exactly ten successful target events.
Preserve separate jmeter.log/configuration evidence.
Predict and explain why result artifacts differ while target work remains equivalent.
Produce a phase-specific debug/load/failure-forensics retention policy.

1. Exact assumptions and hard ceilings

Item	Checkpoint baseline
JMeter	Apache JMeter 5.6.3.
Java	Java 17 JDK; JMeter 5.6.3 requires Java 8+.
Plugins	None.
Target	`http://127.0.0.1:8022` only.
Fixture	Python stdlib `prompt22-listener-fixture-v1`.
Response	~8 KiB synthetic JSON with fake `@example.invalid` and `FAKE-TOKEN` markers.
Heavy variant	GUI, 1 thread ×10 loops, View Results Tree, XML full response/sampler/header fields.
Lean variant	CLI, 1 thread ×10 loops, View Results Tree disabled, metadata-only CSV via `-l`.
Pacing	50 ms both variants.
Max duration	≤10 seconds each.
Target work	Exactly 10 successful work events per variant.
Evidence	JTL/XML size/content, heap/CPU snapshot, jmeter.log, target events, privacy scan, retention policy.

Abort: non-loopback target, >10 samples/variant, any real PII/credential, View Results Tree run beyond the stated tiny ceiling, unexpected JTL/result path, generator memory pressure, repeated errors, or target work count mismatch.

2. Setup and authorization/preflight

Start fixture and verify health.
Record JMeter/Java versions and generator free disk.
Verify the JMX target is 127.0.0.1:8022.
Confirm heavy and lean configs both resolve to 1 thread ×10 loops ×50 ms pacing for this checkpoint.
Record baseline target work count and ensure result directories are new.

3. Predictions before running

Prediction A — target: both variants generate exactly 10 HTTP work requests; target service timing/distribution should be broadly similar because workload is identical.

Prediction B — artifact: heavy XML is much larger per sample because it serializes the ~8 KiB body plus request/response/sampler metadata; lean CSV contains one compact metadata row per sample.

Prediction C — privacy: fake token/email markers appear in heavy XML but not lean CSV.

Prediction D — generator: heavy GUI/result retention should use more heap/CPU/disk work than lean CLI, but the precise memory percentage is machine-dependent and must be measured rather than invented.

4. Heavy debug variant — exact bounded actions

Start JMeter GUI with the heavy debug properties or configure equivalent listener Save Configuration.
Set/check 1 thread, 10 loops, 50 ms pacing.
Enable View Results Tree.
Configure the debug result file results/p22-check-heavy/results.xml with XML + response data + sampler data + request/response headers.
Capture pre-run process working set/heap.
Run exactly 10 samples.
Capture post-run process state and stop; do not continue interacting with the listener as a load test.
Preserve results.xml and GUI/run jmeter.log.

5. Verify heavy evidence

python tools/analyze_artifacts.py results/p22-check-heavy/results.xml
python tools/privacy_scan.py results/p22-check-heavy/results.xml
python tools/analyze_events.py results/server-events.jsonl p22-check-heavy

Require 10 samples, 10 target work events, response-data nodes present, fake privacy markers present, and no real Authorization/Cookie marker.

6. Lean variant — same workload, different result policy

Disable View Results Tree. Use a checkpoint copy of lean properties with threads=1, loops=10, pacing.ms=50 while retaining CSV metadata-only save fields.

PowerShell:

New-Item -ItemType Directory -Force .\results\p22-check-lean | Out-Null

& "$env:JMETER_HOME\bin\jmeter.bat" `
  -n `
  -t .\plans\cli-listener-lab.jmx `
  -q .\config\lean-checkpoint.properties `
  -Jrun.id=p22-check-lean `
  -l .\results\p22-check-lean\results.jtl `
  -j .\results\p22-check-lean\jmeter.log

Capture generator process/heap state at comparable points. Keep JVM settings unchanged.

7. Verify lean evidence

python tools/analyze_artifacts.py results/p22-check-lean/results.jtl
python tools/privacy_scan.py   results/p22-check-lean/results.jtl   results/p22-check-lean/jmeter.log
python tools/analyze_events.py results/server-events.jsonl p22-check-lean

Require 10 CSV samples, 10 target work events, zero fake-token/email hits in JTL, zero real Authorization/Cookie hits, and no unexplained JMeter errors.

8. Quantify result-cost differences

Compare:

Metric	Heavy debug	Lean load	Interpretation
Target work events	10	10	Workload equivalence gate.
JTL samples	10	10	Same sample count.
Response-data nodes	10 expected	0	Body retention changed.
Fake token/email hits	present	0 expected	Privacy surface changed.
Result file bytes	large	small	Disk/artifact cost.
Generator working set/heap	measure	measure	GUI/body retention impact; no invented ratio.
Generator CPU	measure	measure	Rendering/serialization difference; target service timing must also be checked.
jmeter.log	preserve	preserve	Engine diagnostics stay separate in both phases.

9. Validity decision

If both variants produced 10 target events and similar target service_wall_ms, but the heavy run used more generator memory/CPU/disk, the difference is attributable primarily to result/debug machinery. Do not compare heavy GUI latency against lean CLI latency as a production performance regression—the execution modes differ.

The checkpoint conclusion is about result-collection cost and policy, not target capacity.

10. Define a phase-specific retention policy

Phase	Allowed evidence	Prohibited/default-off
Authoring/debug	View Results Tree, tiny sample count, selected response/header/body inspection, short-lived XML if needed	Sustained load; real secrets/PII; unlimited listener entries.
Load/regression	CLI `-l` lean CSV, timing/status/bytes/thread fields, jmeter.log, manifest/target metrics	GUI detailed listeners; response bodies; request/response headers unless explicitly justified.
Failure forensics	small authorized reproduction; narrowly scoped body/header/sample capture; preserve first failure	Broad capture across whole load; deleting original failure evidence.
Real-time operations	aggregate console/backend metrics + lean forensic JTL as required	Assuming backend telemetry has zero generator/network cost.
Long-term retention	raw lean JTL/log/manifest according to governance; reproducible derived reports	Sensitive debug bodies beyond required retention.

11. Required evidence packet

JMeter 5.6.3 / Java 17 / no-plugin assumptions.
Heavy and lean listener/result configurations.
Heavy XML and lean CSV file sizes/sample counts.
Generator pre/post CPU/working-set/heap snapshots.
Run-specific jmeter.log files.
Privacy-scan output.
Target event counts/service timing for both run IDs.
Configured 10 vs achieved 10 sample/work proof.
Final phase-specific retention policy.

12. Validity statement

Example: “Apache JMeter 5.6.3/Java 17 executed the same 1-thread ×10-loop ×50 ms localhost workload against prompt22-listener-fixture-v1. The heavy debug variant enabled View Results Tree and XML response/sampler/header retention; the lean variant disabled GUI detailed listeners and used CLI -l metadata-only CSV. Both produced 10 successful target work events. Heavy XML contained synthetic FAKE-TOKEN/example.invalid body data and was materially larger; lean CSV did not retain those markers. Generator working-set/heap/CPU and result-file sizes were recorded rather than assumed. Run-specific jmeter.log and target event evidence remained available in both variants. This demonstrates result-collection/privacy/generator-cost differences under identical tiny local target work; it is not a production capacity comparison.”

13. Verification checklist

Only 127.0.0.1:8022.
Heavy and lean use identical 1×10×50 ms checkpoint workload.
View Results Tree used only in bounded heavy debug run.
Heavy XML includes response-data nodes and fake markers.
Lean CSV contains no response body/fake markers.
Both target event counts equal 10.
Generator CPU/heap/disk evidence recorded.
jmeter.log preserved separately for both.
No real secrets/PII or Authorization/Cookie capture.
Retention policy approved before scaling any load.

14. Cleanup / rollback

Stop GUI/CLI runs and localhost fixture after evidence capture.
Clear View Results Tree and leave it disabled in the load-ready JMX.
Keep first-failure/heavy and lean evidence until review; delete only after the retention decision permits it.
Delete disposable fake-body debug artifacts after the documented short retention window.
No production/public target, real credential/PII, recorder CA, remote engine, container, paid telemetry, CI secret, OS/JVM tuning or external database/message/API was changed.

15. What Chapter 22 adds to the operating model

The production performance-testing operating model now has a result-collection and retention contract: every phase declares allowed listeners, save-service fields, response/header/body policy, JTL format, sample variables, aggregate/backend consumers, generator heap/CPU/disk/network budget, privacy scan/classification, first-failure retention, jmeter.log ownership, configured-versus-achieved workload check, and evidence cleanup period before a run is accepted.

Chapter 23 moves to HTML Dashboard Reports and Performance Result Interpretation. It assumes Chapter 22 has already produced trustworthy lean JTL and teaches how to derive, validate, read and communicate the dashboard without confusing report presentation with raw evidence.

Knowledge check

Why must the checkpoint use 10 target samples in both variants?

What does a fake-token hit in heavy XML prove?

If View Results Tree lags but target service_wall_ms and lean JTL remain low, what failed?

Why isn't 'heavy used 20% more heap' stated in advance?

What is Chapter 23's prerequisite from this checkpoint?

Next chapter

HTML Dashboard Reports and Performance Result Interpretation

Chapter 23 turns trusted JTL into dashboard evidence and teaches correct interpretation of latency, throughput, errors and distributions.

Official references and version notes

JMeter User Manual — Listeners — result-file formats, save-service fields, CLI -l, memory guidance, CSV/XML capabilities, response-data cost, and sample variables.
Component Reference — View Results Tree — explicit warning against load-test use, entry/response display limits, and debug behavior.
Component Reference — Simple Data Writer — efficient file output without GUI rendering.
Component Reference — Summary Report — aggregate summary behavior and lower memory use than detailed per-sample GUI views.
JMeter Properties Reference — current jmeter.save.saveservice.* defaults, auto-flush trade-off, CLI summariser, and result configuration.
JMeter Best Practices — CLI load mode, few listeners, no View Results Tree/Table during load, CSV, and only required fields.
Apache JMeter downloads — current stable release and Java requirement.

Version and compatibility note

Version-sensitive statements were rechecked against current Apache JMeter primary documentation on 2026-09-05. The course baseline remains Apache JMeter 5.6.3 with a Java 17 JDK; JMeter 5.6.3 requires Java 8+. Current documentation says View Results Tree MUST NOT BE USED during load testing because it consumes substantial memory and CPU; it is intended for functional/debug/validation work. Its displayed entry count defaults to 500 via view.results.tree.max_results; response display is also bounded by view.results.tree.max_size (200K default in current documentation), but response data can still exist in the SampleResult. Listeners can consume large amounts of memory because many keep samples they display. The documented low-memory choices include Simple Data Writer and Summary Report; Aggregate Report/Graph aggregate samples rather than retaining every individual sample. JMeter explicitly recommends Simple Data Writer plus CSV to minimize memory. The CLI -l listener is controlled by save-service properties. Current result defaults use CSV; response_data=false, samplerData=false, request/response headers false, bytes true, sent bytes true, thread counts true, and CSV field names true. Response data cannot be stored in CSV; XML can store text response data but can become very large. jmeter.save.saveservice.autoflush=true can reduce result loss on crash but has a performance cost, particularly in intensive tests, and is false by default.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20

0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0 Send only Ethereum/ERC-20 compatible assets to this address.