Checkpoint Lab — CSV Data Set Config, Parameterization, Unique Data, and Test Data Strategy

1. Assumptions and ceilings

2. Generate data and start a clean fixture

python tools/make_data.py
python fixtures/data_fixture.py --log results/checkpoint/server-events.jsonl
curl --fail --silent http://127.0.0.1:8000/health
curl --fail --silent http://127.0.0.1:8000/reset

Archive shards/manifest.json with the run evidence before any load.

3. Workload Class A — stable reusable account per thread

CSV Data Set Config:

Sampler:

/account?user_id=${user_id}&thread=${__threadNum}

Each file contains one account. Two threads × three outer loops therefore intentionally reread the same account only within the owning thread.

4. Workload Class B — one-time token per iteration

CSV Data Set Config:

Sampler:

/one-time?token=${token}&thread=${__threadNum}

Two threads × three loops demand exactly six rows. The generated file contains six tokens, so the planned data capacity exactly matches the configured outer iterations.

5. Predict before running

1. Class A: two unique account IDs, each owned by exactly one JMeter thread across all three loops; zero 409 collisions.
2. Class B: exactly six distinct tokens, each observed once; zero <EOF> values and zero 409 reuse failures.
3. All-threads Class B does not guarantee which thread gets OT-0001; only global uniqueness is guaranteed.
4. If Class B data shrinks to four rows while demand remains six and Stop Thread=true, achieved business samples will be data-limited below the configured six.

6. Run Class A

jmeter -n   -t plans/checkpoint-class-a.jmx   -l results/checkpoint/class-a.jtl   -j results/checkpoint/class-a.log   -Jjmeter.save.saveservice.print_field_names=true   -Jjmeter.save.saveservice.thread_counts=true

python tools/analyze_data_events.py results/checkpoint/server-events.jsonl

Verify /stats shows two account owners and no collisions.

7. Reset and run Class B

curl --fail --silent http://127.0.0.1:8000/reset

jmeter -n   -t plans/checkpoint-class-b.jmx   -l results/checkpoint/class-b.jtl   -j results/checkpoint/class-b.log   -Jjmeter.save.saveservice.print_field_names=true   -Jjmeter.save.saveservice.thread_counts=true

python tools/analyze_data_events.py results/checkpoint/server-events.jsonl

Verify exactly six distinct tokens were accepted. Preserve raw JTL and matching logs for both workload classes.

8. Intentionally break Class A sharing

Create a failure copy:

• Filename becomes common data/accounts.csv.
• Sharing remains Current thread.
• 2 threads × 1 loop.

Both private cursors start at row 1. The fixture should record one account owner and at least one 409 collision from the other thread. Preserve the failed sample/event, then restore thread-specific filenames.

9. Intentionally break Class B EOF/recycle policy

Create a three-row one-time file, keep 2 threads × 3 loops, and set Recycle=true. Six iterations consume the three rows twice.

Expected: three first-use successes followed by reuse/collision failures as rows recycle. Restore the full six-row file and Recycle=false/Stop=true.

10. Optional EOF-sentinel diagnostic

With the same short three-row file, set Recycle=false and Stop=false for one bounded run. After valid rows are exhausted, target evidence should show invalid <EOF> data (possibly URL-encoded on the wire). Preserve it, then return to Stop=true for the valid checkpoint profile.

11. Build the distributed uniqueness plan

The generated manifest should prove:

Both engines can run the same JMX Filename=data/users.csv. Deployment places a different disjoint file at that path on each engine.

Before a real authorized distributed run, verify on every engine: path exists, row count is expected, SHA-256 equals the manifest, JMeter/Java versions match, and no engine received another engine's shard.

12. Distributed row math

If two engines each run 2 threads × 3 one-time iterations, global demand is:

2 engines × 2 threads/engine × 3 iterations/thread = 12 globally unique rows

Two six-row disjoint shards exactly satisfy that example. If an engine fails to start, achieved global load/data consumption is lower; do not quietly redistribute rows mid-run without an explicit revised workload contract.

13. Required evidence packet

14. Verification checklist

• All traffic is loopback and bounded.
• No real PII/password/token appears in CSV/JTL/logs.
• Class A shows stable exclusive account ownership per thread.
• Class B consumes six unique rows without recycling.
• Intentional account collision and recycle/EOF failure are preserved before repair.
• Configured versus achieved sample counts are explained when EOF stops threads.
• Engine shards are disjoint and explicitly mapped by manifest/hash.
• No live distributed engine/RMI setup was needed.

15. Validity statement

16. Cleanup

1. Stop the local Python fixture.
2. Preserve valid/broken evidence until review is complete.
3. Delete disposable generated datasets if run policy requires it; retain generator script/manifest/hash for provenance.
4. Never archive real credentials/PII with JTL or CSV artifacts.
5. No production target, real identity, remote RMI engine, paid platform, plugin, container, database, or system-wide JVM/OS setting was changed.

17. What Chapter 11 adds to the operating model

The performance-testing operating model now has a test-data allocation contract: schema, source provenance, row count, sharing/cursor domain, recycle/EOF policy, per-user ownership, privacy classification, file deployment, distributed shard mapping, and cleanup are reviewed alongside workload and results.

Chapter 12 builds on this data contract with Controllers: Simple, Loop, Transaction, If, While, Switch, and Throughput, allowing the test tree to control business-flow repetition/branching without accidentally advancing or reusing data in the wrong scope.

Knowledge check

Official references and version notes

• Component Reference — CSV Data Set Config — row timing, headers, quoting, relative paths, EOF behavior, sharing modes, and per-thread file example.
• Remote (Distributed) Testing — remote engines execute the plan and have their own local runtime/filesystem state.
• Getting Started — GUI authoring/debugging and CLI execution conventions.
• Best Practices — generator validity, lean listeners, and pre-generated data guidance.
• Apache JMeter downloads — current production release and Java requirement.