Rangsh opened a new pull request, #12173:
URL: https://github.com/apache/seatunnel/pull/12173

   ## Summary
   
   Closes #12063
   
   This PR addresses the high sample-to-sample variance reported for:
   
   - `IMapJobStorageBenchmark.runningJobGrowth`
   - `IMapJobStorageBenchmark.completedJobHistoryGrowth`
   
   ### Root cause
   
   Investigation shows the variance is primarily driven by the **benchmark 
fixture**, not by IMap cardinality failing to reset between iterations:
   
   1. **Per-iteration full WAL reload**: `FileMapStore.loadAll` always replays 
the entire append-only WAL. The growth fixture previously ran `evict` + 
`loadAll` in every JMH iteration tear-down, injecting growing GC / page-cache 
cost into the next measured SingleShot sample.
   2. **Fixed growth keys**: growth batches reused the same key range every 
iteration, unlike the transition / DAG store fixtures that allocate unique keys 
per batch.
   3. **Completed-path double write-through** (production): 
`JobHistoryService.storeFinishedPipelineMetrics` used `computeIfAbsent` + 
`put`, causing two durable MapStore writes for a newly finished job under 
write-through storage.
   
   In-memory IMap size is already restored between iterations; durability 
semantics (write-through WAL / FileMapStore persistence) are preserved.
   
   ### Changes
   
   - **Benchmark fixture** (`IMapJobGrowthBenchmarkWorkload`):
     - Allocate unique growth keys per iteration.
     - Keep resident size/content checks in iteration tear-down.
     - Move durable MapStore reload sampling to **trial** tear-down (once per 
fork).
   - **Production** (`JobHistoryService.storeFinishedPipelineMetrics`):
     - Merge existing metrics in memory, then issue a **single** TTL `put`.
     - Finished-state / finished-metrics durability and TTL behavior are 
unchanged.
   - **Test**: `JobHistoryServiceFinishedMetricsTest` asserts one write for a 
new job and correct merge for existing metrics.
   
   ## Local results
   
   Same JDK / JMH args / storage config for both methods 
(`initialStoredJobCount=0`, forks=3, warmup=3, measurement=5, SingleShotTime):
   
   | Benchmark | Score | Error | Error% |
   | --- | ---: | ---: | ---: |
   | `runningJobGrowth` | 153.798 us/op | ±51.875 | 33.7% |
   | `completedJobHistoryGrowth` | 986.768 us/op | ±96.541 | 9.8% |
   
   Notes:
   
   - Absolute scores are from a local machine and are **not** comparable to the 
GitHub Actions baseline in #12063.
   - CI before/after on the same runner class should be used for the official 
Score / Error / CV comparison.
   - Fixture correction means score differences vs the old fixture should not 
be presented as a production speedup by themselves; the 
`storeFinishedPipelineMetrics` change is the production latency reduction on 
the completed path.
   
   ## Correctness
   
   - Running-job and completed-job resident state checks remain per iteration.
   - Durable MapStore reload validation still runs once per trial for the last 
growth phase.
   - Finished metrics still merge and persist with the configured history TTL.
   - Unit test covers single-write and merge behavior for 
`storeFinishedPipelineMetrics`.
   
   ## Test plan
   
   - [x] `./mvnw -Pbenchmark spotless:apply -pl 
seatunnel-benchmarks,seatunnel-engine/seatunnel-engine-server`
   - [x] `JobHistoryServiceFinishedMetricsTest` (2 tests)
   - [x] Local JMH: `IMapJobStorageBenchmark.runningJobGrowth` / 
`completedJobHistoryGrowth` with `initialStoredJobCount=0`
   - [ ] CI / Benchmarks Diagnostics before-after on the same runner for both 
methods and both `initialStoredJobCount` values (`0`, `1000`)
   - [ ] Confirm WAL / FileMapStore durability semantics unchanged in review
   
   
   Made with [Cursor](https://cursor.com)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to