flowcontrol: add benchmark suite#2539
Conversation
|
@LukeAVanDrie: The label(s) DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
/assign @kfswain |
428658c to
7cbbe72
Compare
|
Great, unless I missed it, can you pls describe the details of the workload (request rate, number of flows, number of priorities) you benchmarked in the PR description? |
This is defined in I just updated the PR description with this information. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, LukeAVanDrie The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Introduces a synchronous steady-state benchmark harness to evaluate the Flow Control layer's algorithmic throughput and scalability.
7cbbe72 to
a8b6b2d
Compare
|
/lgtm |
* flowcontrol: add benchmark suite Introduces a synchronous steady-state benchmark harness to evaluate the Flow Control layer's algorithmic throughput and scalability. * rebase onto main
…ce-extension#2539) * flowcontrol: add benchmark suite Introduces a synchronous steady-state benchmark harness to evaluate the Flow Control layer's algorithmic throughput and scalability. * rebase onto main
What type of PR is this?
/kind test
What this PR does / why we need it:
This PR introduces a comprehensive, steady-state benchmarking suite for the Flow Control layer. This suite is essential for establishing baseline performance metrics, identifying concurrency bottlenecks, and ensuring we prevent regressions as the system scales.
Results:
Results were collected on Intel(R) Xeon(R) CPU @ 2.20GHz using 8 cores for reference via:
The bulk of the testing is driven by
BenchmarkFlowController_PerformanceMatrixwhich affixes and sweeps the following values, yielding a full performance hypercube:{free-flow (always unsaturated), 1, 100}{1, 8}{1, 8}{10, 50000}{10, 5000, 50000}In short, the Flow Control layer is working efficiently. The dominant blocking factor is standard channel backpressure (
selectgo) which is expected with our queuing strategy. There is minimal, localized lock contention. The primary limiter of raw macroscopic throughput is Garbage Collection overhead generated by allocations duringIterateQueuesand vending theFlowQueueAcessor. Both of these are clear, isolated targets for zero-allocation strategies. I have already fixed and validated this locally. I will send targeted performance improvements as followup PRs.benchstatWhich issue(s) this PR fixes:
Part of #2087
Does this PR introduce a user-facing change?: