nzw921rx opened a new issue, #12059: URL: https://github.com/apache/seatunnel/issues/12059
## Description This is a focused investigation and improvement task for the throughput variance observed in the intermediate queue benchmarks. It is not a performance regression report and does not attempt to compare the performance of Java 8 with Java 11. The benchmark results show noticeable sample-to-sample variance within individual runs: | Benchmark | Java 8 Error / CV | Java 11 Error / CV | | --- | ---: | ---: | | `blockingQueueRecordHandoff` | 10.76% / 10.06% | 9.95% / 9.31% | | `disruptorRecordHandoff` | 22.46% / 21.01% | 18.35% / 17.16% | Benchmark run: https://github.com/apache/seatunnel/actions/runs/33723940255 Other benchmarks executed by the same workflow were substantially more stable. The intermediate queue results are therefore worth investigating to determine whether the variance comes from the benchmark fixture, queue implementation, thread scheduling, or execution environment. The goals of this issue are to: 1. Identify and explain the source of the throughput variance. 2. Improve the benchmark fixture or methodology if it causes the instability. 3. Optimize the production queue path if profiling confirms an implementation bottleneck. 4. Preserve the correctness and lifecycle behavior of both queue implementations. ## Relevant benchmarks ```text IntermediateQueueBenchmark.blockingQueueRecordHandoff IntermediateQueueBenchmark.disruptorRecordHandoff ``` ## Profiling tools For an overview of the Zeta benchmark suite and usage, see the [SeaTunnel Zeta Benchmark Guide](https://seatunnel.apache.org/docs/engines/zeta/benchmark). SeaTunnel provides the `Benchmarks Diagnostics` workflow for running one exact benchmark method with CPU, wall-clock, lock, GC, or JFR profiling: https://github.com/apache/seatunnel/actions/workflows/benchmarks_diagnostics.yml The benchmark can also be run directly from the GitHub Actions page by selecting **Benchmarks Diagnostics**, clicking **Run workflow**, and providing the target branch, tag, commit SHA, or trusted PR number together with the exact benchmark method. ## Local profiling Build the benchmark module: ```bash ./mvnw -Pbenchmark -pl seatunnel-benchmarks -am -DskipTests package ``` Run a profiler locally: ```bash bash tools/benchmarks/profile_benchmarks.sh profile cpu \ --repository . \ --benchmark 'IntermediateQueueBenchmark.disruptorRecordHandoff$' ``` Replace `cpu` with `wall`, `lock`, or `gc` as needed. The same command can be used for: ```text IntermediateQueueBenchmark.blockingQueueRecordHandoff$ ``` Capture a JFR recording: ```bash bash tools/benchmarks/profile_benchmarks.sh capture jfr \ --repository . \ --benchmark 'IntermediateQueueBenchmark.disruptorRecordHandoff$' ``` CPU, wall-clock, and lock profiling require `ASYNC_PROFILER_HOME`. The GitHub Actions workflow installs the required profiler automatically. ## Expected outcome This issue should result in both root-cause analysis and a focused improvement: - Identify and explain the primary source of the benchmark variance. - Improve the benchmark when the fixture or methodology is responsible. - Optimize the production queue path when an implementation problem is confirmed. - Provide before-and-after results collected with the same JDK, runner, benchmark arguments, and queue parameters. - Compare both throughput and variance before and after the change. - Add appropriate tests and confirm that queue correctness remains unchanged. The implementation should focus on the confirmed source and avoid unrelated queue refactoring. -- 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]
