Support 500 server sessions: load test, default MaxSessionCount=500, bottleneck analysis#3922
Support 500 server sessions: load test, default MaxSessionCount=500, bottleneck analysis#3922Copilot wants to merge 4 commits into
Conversation
|
|
…0, document bottlenecks
| @@ -0,0 +1,117 @@ | |||
| # Server session scalability and the 500-session load test | |||
There was a problem hiding this comment.
I am not sure this is a good place for this doc, it would be better to add something to benchmarks.md or sessions.md, but not in its verbosity, ideally more "This implementation has been tested to achieve x concurrent sessions (client/server) with n subscription x m items with x config. (maybe some matrix) with the following CPU and memory usage. Then in addition to the base line test here, we create a macro benchmark and produce some numbers. What do you think?
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3922 +/- ##
==========================================
- Coverage 72.79% 72.78% -0.01%
==========================================
Files 917 917
Lines 149563 149563
Branches 25918 25918
==========================================
- Hits 108875 108861 -14
- Misses 31236 31243 +7
- Partials 9452 9459 +7 🚀 New features to boost your workflow:
|
Description
Adds a 500-session server load test, raises the default session limit to 500, and documents the bottlenecks found while profiling the server at that scale.
ServerConfiguration.MaxSessionCountdefault changed100 → 500(ApplicationConfiguration.cs). Updated the default-value round-trip tests accordingly.[Explicit]ServerManySessionsLoadTestAsyncinLoadTest.cs— 500 sessions, each aManagedSessionwith one slow-publishing (1000 ms) subscription (added viaManagedSession.AddSubscriptionon the V2 SubscriptionManager) on a shared value node; a writer drives changes for 60 s; asserts every session receives notifications under load. Session count and duration are fixed defaults (500 sessions, 60 s). Connect is throttled (~ProcessorCount × 4), reuses a single resolved endpoint instead of per-session discovery, and retries transient connect timeouts, and the fixture runs atWarninglog level to avoid per-publish logging overhead.ClientTestFrameworkgains a settableMaxSessionCount(applied to the server config) so fixtures can host 500+ sessions.Docs/SessionScalability.md(linked fromDocs/README.md) covers the new default and the profiling findings.Bottlenecks found (ordered by impact):
Basic256Sha256RSA handshakes serialize on cores; bulk connect throughput scales with core count, and bursts surface asBadRequestTimeout. Mitigated client-side via throttling, single-endpoint reuse, and retries.Publishtimeouts (sharedMaxRequestThreadCountpool).Related Issues
Checklist
Put an
xin the boxes that apply. You can complete these step by step after opening the PR.