[
https://issues.apache.org/jira/browse/YUNIKORN-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aditya Maheshwari updated YUNIKORN-3361:
----------------------------------------
Description:
# *Go {{testing.B}} Execution Model Mismatch ({{{}b.N{}}} ignored)*
** *Issue:* In Go benchmarks, {{b.N}} determines iteration count.
{{performance_test.go:189-200}} runs a fixed workload once per {{b.Run}}
without wrapping logic in {{for i := 0; i < b.N; i++}} or guarding against
{{{}b.N > 1{}}}.
** *Impact:* If {{go test -bench}} increases {{b.N}} (when execution finishes
quickly), the setup and allocation state accumulates across runs without
resetting.
** *Comparison:* In contrast, the shim benchmark {{scheduler_perf_test.go:74}}
includes a safeguard {{{}if b.N > 1 \{ b.Skip() }{}}}.
# *Inaccurate Timing Window ({{{}b.ResetTimer(){}}} placement)*
** *Issue:* {{UpdateAllocation}} is called at {{performance_test.go:148-168}}
_before_ {{b.ResetTimer()}} at {{{}performance_test.go:174{}}}.
** *Impact:* {{UpdateAllocation}} dispatches asks asynchronously to the
scheduler core event queue. The core starts processing and allocating pods in
background goroutines _before_ {{b.ResetTimer()}} executes. Consequently, a
portion of the scheduling work occurs before timer reset, leading to
artificially inflated (faster) reported throughput.
# *Polling Latency Overhead in {{waitForMinAllocations}}*
** *Issue:* mockRM.waitForMinAllocations polls {{len(m.Allocations)}} using
{{{}common.WaitForCondition(10*time.Millisecond, ...){}}}.
** *Impact:* Adds up to 10 ms of polling jitter to measured duration per test
run.
# *Missing Allocation and Custom Metrics*
** *Issue:* {{b.ReportAllocs()}} and custom metrics via {{b.ReportMetric()}}
are omitted.
** *Impact:* Standard Go benchmark outputs like {{B/op}} (heap allocation
size) and {{allocs/op}} (allocation count) are missing, hiding garbage
collection pressure and memory usage patterns during scaling.
> Improve performance tests in yunikorn-core
> ------------------------------------------
>
> Key: YUNIKORN-3361
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3361
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: core - scheduler
> Reporter: Aditya Maheshwari
> Assignee: Aditya Maheshwari
> Priority: Major
>
> # *Go {{testing.B}} Execution Model Mismatch ({{{}b.N{}}} ignored)*
> ** *Issue:* In Go benchmarks, {{b.N}} determines iteration count.
> {{performance_test.go:189-200}} runs a fixed workload once per {{b.Run}}
> without wrapping logic in {{for i := 0; i < b.N; i++}} or guarding against
> {{{}b.N > 1{}}}.
> ** *Impact:* If {{go test -bench}} increases {{b.N}} (when execution
> finishes quickly), the setup and allocation state accumulates across runs
> without resetting.
> ** *Comparison:* In contrast, the shim benchmark
> {{scheduler_perf_test.go:74}} includes a safeguard {{{}if b.N > 1 \{ b.Skip()
> }{}}}.
> # *Inaccurate Timing Window ({{{}b.ResetTimer(){}}} placement)*
> ** *Issue:* {{UpdateAllocation}} is called at
> {{performance_test.go:148-168}} _before_ {{b.ResetTimer()}} at
> {{{}performance_test.go:174{}}}.
> ** *Impact:* {{UpdateAllocation}} dispatches asks asynchronously to the
> scheduler core event queue. The core starts processing and allocating pods in
> background goroutines _before_ {{b.ResetTimer()}} executes. Consequently, a
> portion of the scheduling work occurs before timer reset, leading to
> artificially inflated (faster) reported throughput.
> # *Polling Latency Overhead in {{waitForMinAllocations}}*
> ** *Issue:* mockRM.waitForMinAllocations polls {{len(m.Allocations)}} using
> {{{}common.WaitForCondition(10*time.Millisecond, ...){}}}.
> ** *Impact:* Adds up to 10 ms of polling jitter to measured duration per
> test run.
> # *Missing Allocation and Custom Metrics*
> ** *Issue:* {{b.ReportAllocs()}} and custom metrics via {{b.ReportMetric()}}
> are omitted.
> ** *Impact:* Standard Go benchmark outputs like {{B/op}} (heap allocation
> size) and {{allocs/op}} (allocation count) are missing, hiding garbage
> collection pressure and memory usage patterns during scaling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
