[test](feut) fix testShouldWarmUpPerformanceRepeatedCycles200k - #66081
Conversation
### What problem does this PR solve? Issue Number: None Related PR: apache#65153 Problem Summary: The repeated-cycle cache hotspot performance test used a 1-second average threshold even though the equivalent 200K-table single-cycle test allows 1.5 seconds. CI hosts occasionally exceeded 1 second while preserving correct matching results. Align the repeated-cycle threshold with the existing 1.5-second allowance and update the assertion message. ### Release note None ### Check List (For Author) - Test: Unit Test - ./run-fe-ut.sh --run org.apache.doris.cloud.CacheHotspotManagerTableFilterTest#testShouldWarmUpPerformanceRepeatedCycles200k - Behavior changed: No - Does this need documentation: No
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
testShouldWarmUpPerformanceRepeatedCycles200k
|
/review |
There was a problem hiding this comment.
Review opinion: approve.
The threshold alignment looks good. The five-cycle test still verifies exact matching for all 1,000,000 calls, and its 1.5-second per-cycle average now matches the existing single-cycle 200K-table oracle. Because OnTablesFilter is immutable and each call uses the same precompiled rule set, the average remains a useful sustained-throughput guard while reducing sensitivity to isolated CI scheduling or GC pauses.
Critical checkpoint conclusions:
- Goal and proof: the focused test-only change accomplishes the stated anti-flakiness goal without altering correctness coverage.
- Scope: minimal and clear; only the threshold and matching assertion message change.
- Concurrency, lifecycle, and locking: no production or shared-state behavior changes; not applicable to this patch.
- Configuration, compatibility, persistence, data writes, and FE-BE propagation: no changes; not applicable.
- Parallel paths and conditions: the revised bound is consistent with the neighboring single-cycle 200K path; production callers remain unchanged.
- Tests and results: the exact match-count assertion and broader 10K/50K/200K/500K, selective, and multi-rule coverage remain intact. No result files change. Per the review-run instructions, I did not execute builds or tests.
- Performance: the 1.5-second bound retains a meaningful regression signal and is well below the default 60-second refresh interval. The microbenchmark's omission of catalog traversal/logging and its averaging behavior predate this patch.
- Observability and other concerns: no runtime observability change is needed, and I found no additional correctness or performance issue.
User focus: no additional review focus was provided; I reviewed the whole PR.
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
TPC-H: Total hot run time: 29239 ms |
TPC-DS: Total hot run time: 178103 ms |
ClickBench: Total hot run time: 25.02 s |
What problem does this PR solve?
Issue Number: None
Related PR: #65153
Problem Summary: The repeated-cycle cache hotspot performance test used a 1-second average threshold even though the equivalent 200K-table single-cycle test allows 1.5 seconds. CI hosts occasionally exceeded 1 second while preserving correct matching results. This change aligns the repeated-cycle threshold with the existing 1.5-second allowance and updates the assertion message.
Release note
None
Check List (For Author)
Test command:
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)