Vivek1106-04 opened a new pull request, #12418: URL: https://github.com/apache/seatunnel/pull/12418
### Purpose of this pull request Adds `CheckpointSchedulingBenchmark`, a JMH benchmark for the checkpoint scheduling layer. Requested by @nzw921rx on https://github.com/apache/seatunnel/issues/12339 so that a change to the scheduling model can be judged on measurements rather than on argument. Today that layer is a blind spot. `CheckpointingTimeBenchmark#checkpointSingleInput` goes through `CheckpointBenchmarkTrigger`, which reflects straight into `createPendingCheckpoint` and `startTriggerPendingCheckpoint`, so the `ScheduledExecutorService` is out of the measured path entirely. Even routed through it, that number would say little: checkpoint completion time is dominated by the barrier ACK round-trip, and the scheduler contributes a queue hop on top of it. So this benchmark measures a different quantity: the delay between a checkpoint trigger becoming due and its scheduling thread running it, sampled as a distribution (`Mode.SampleTime`, so p50/p99/max rather than a mean). That is the part the scheduling model decides, and it is the one that matters for correctness-adjacent behaviour - a trigger delayed past `checkpointMinPause` or the timeout window shows up here and nowhere else. The axis it sweeps is the pipeline count. Every `CheckpointCoordinator` builds its own pool: ```java this.scheduler = Executors.newScheduledThreadPool(2, ...); // per (jobId, pipelineId) ``` so a member running P pipelines carries 2P scheduler threads. `pipelineNum` sweeps 1 / 10 / 100 / 500 against that. Parameters: | Parameter | Default | Why | |---|---|---| | `pipelineNum` | 1, 10, 100, 500 | Pipelines scheduling on the member; also sets the scheduler thread count. | | `checkpointIntervalMillis` | 1000 | Interval of the background trigger load. Far below the production default of 300000 so a short iteration sees a realistic number of triggers. | | `triggerBodyMicros` | 0, 500 | How long a trigger occupies its scheduling thread. A parameter rather than a fixed cost: it is what decides whether a given pool width is wide enough, and it is not the same for every deployment. | Two deliberate choices worth review: - The measured task only signals. The per-trigger work lives in the background load, so a sample contains queueing plus wake-up and not the body cost. - `triggerBodyMicros` sleeps rather than spins. A real trigger body waits on the coordinator lock and on checkpoint id allocation - it holds its thread without consuming a core, and that is the shape that decides pool width. This is benchmark-only code. No engine, connector or API change. ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? `CheckpointSchedulingBenchmarkTest` covers the harness: every scheduled trigger runs under background load, every pipeline's periodic trigger fires, the scheduler threads are counted by name, teardown leaves none behind, and out-of-range parameters are rejected. ``` ./mvnw -Pbenchmark -pl seatunnel-benchmarks test -Dtest=CheckpointSchedulingBenchmarkTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 ``` The benchmark itself was smoke-run to confirm it reports a sane distribution (`-f 1 -wi 1 -i 2 -w 2s -r 3s`, `triggerBodyMicros=500`, macOS, `-XX:ActiveProcessorCount=4` as the benchmark pins): | `pipelineNum` | p50 | p99 | max | |---|---|---|---| | 1 | 6.83 us | 10.62 us | 856 us | | 100 | 8.32 us | 13.46 us | 937 us | That is a smoke run, not a result - single machine, one fork, two iterations. I will post a full sweep with the configured forks and iterations on this PR, and the same sweep run against #12165, so the two scheduling models can be compared on identical settings. ### Check list * [x] If any new Jar binary package adding in your PR, please add License Notice according [New License Guide](https://github.com/apache/seatunnel/blob/dev/docs/en/developer/new-license.md) * [x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs * [x] If necessary, please update `incompatible-changes.md` to describe the incompatibility caused by this PR. * [x] If you are contributing the connector code, please check that the following files are updated No new dependency (JMH is already a benchmark-module dependency), no user-facing change, no incompatibility, no connector code. `seatunnel-benchmarks/README.md` documents how to run the benchmark and sweep the pipeline count. -- 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]
