Vivek1106-04 commented on PR #12418:
URL: https://github.com/apache/seatunnel/pull/12418#issuecomment-5807752698
The fixture is pushed (`afd311519`, `be57ed0ae`) and the PR description is
rewritten to match it.
**@SEZ9**
1. The note is at the timed spin loop in
`CheckpointSchedulingFixture#awaitTrigger`: why `expected` is a few
microseconds early, that the offset is identical on every scheduler compared,
and not to move the start later.
2. The limit is 10% of due triggers per iteration. Skips are printed every
iteration, pass or fail, split by cause. Running it made me split one level
further than you asked, because the causes turned out to mean different things:
```
# measured 100 of 101 due triggers; skipped 0 with a checkpoint already
pending before the due time,
# 0 that came due while another trigger was being measured, 1 where
parking overran the due time,
# 0 that ran before their estimated due time
```
"Setup overran" is now three counters: came due during another sample,
parking overshot, and ran before the estimate (which would mean the phase
estimate is wrong).
**@nzw921rx** The boundaries are the ones in my last comment: the untimed
`@Setup(Level.Invocation)` ends at the due time, and the timed `@Benchmark`
ends when `pendingCounter` goes from 0 to 1. For CV I went with (a):
`save_jmh_result.py` now reads `rawDataHistogram`. Its new test failed before
the fix. On the local sweep it now reports CV from 3.4% to 17%, plus 81% for
`dev` at 500 pipelines, where the macOS distribution splits between two timer
behaviours. Before the fix it reported 0% for every point.
**@DanielLeens** Both reflected fields and both faked task messages have a
comment at their read site. A missing field fails at setup with the class and
field named, which `shouldNameTheEngineFieldWhenItNoLongerExists` covers.
**Three things the runs changed, compared with what I described earlier:**
- **Only a fixed subset of coordinators is measured.** Measuring every
coordinator, a run on #12165 at 10 pipelines skipped 62 of 250 due triggers,
all as "came due while another trigger was being measured". Phases drift as
delays vary, so due times bunch up. Dropping the second of two
near-simultaneous triggers biases the result towards short delays exactly under
contention, which is the case this benchmark exists for. So probes are now
every k-th coordinator, started at least 100 ms apart, and the rest are load.
Probe triggers still collide with the load, and which coordinators are probes
is fixed by index, so the samples carry no selection. After the change, that
same run skipped 2 of 305.
- **IMap persistence is off.** I first reused the storage benchmarks'
member. Its write-through MapStore puts a file write on a partition thread for
every engine IMap update, and a thread dump showed checkpoint id allocation
blocked there for over 600 ms. The fixture keeps that member's isolated
checkpoint storage but disables the MapStore.
- **The interval is `pipelineNum * 20 ms`, floored at 200 ms, not a flat 10
s.** Every point of the sweep then sees the same trigger rate and storage load.
500 pipelines is still 10 s, and the floor keeps 1 pipeline from sending
triggers down the 500 ms pending re-arm path.
Local sweep, `dev` against #12165 at `c773cc091`, the same benchmark code on
both, full table in the description: all four pipeline counts pass on both,
with at most 2 skips per point, and scheduler threads at 500 pipelines are 995
against 10. I have left the delay numbers out on purpose: on macOS every timed
wait fires about 5 ms late, so the local distribution sits on that floor. The
delay comparison needs the Linux runners.
@nzw921rx @DanielLeens @SEZ9 ready for the final pass.
--
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]
