Curated, with judgment attached

The canonical starting point: circuit memory behaviour, scalability guidance, and load-balancer/affinity requirements. Read this before trusting any sizing rule of thumb.

Circuit handler configuration, reconnect behaviour, and the knobs (DisconnectedCircuitMaxRetained, JSInterop timeouts) that directly drive the disconnected-circuit memory line in any capacity model.

Reads as a security doc but doubles as the best description of resource exhaustion risks: per-circuit memory, connection limits, and denial-of-service surface.

Our interactive model for nodes, SignalR units, memory, and message budget. Open source; the formulas are documented in the tool's glossary.

Connection counts and message throughput per unit, with methodology. The numbers behind every 'connections per unit' assumption; verify against your tier before committing.

The decision doc for Azure SignalR Service vs. self-managed Redis backplane: sticky sessions, scale-out patterns, and their trade-offs.

Included messages per unit per day by tier. SKU terms change; this page, not a blog post, is the source of truth for the message-budget inputs.

Map of the whole dotnet-* diagnostics family (counters, trace, gcdump, dump) and when to reach for each.

First tool out of the bag in a soak test: live GC heap size, working set, and SignalR connection counters with zero profiler overhead.

Heap snapshots you can diff: the practical way to attribute per-circuit memory cost and catch circuit-scoped leaks.

Server GC vs. workstation GC and generation behaviour: context you need before interpreting any memory number on a Blazor Server node.

The classic traps (captured HttpContext, unbounded caches, large object heap churn), most of which get amplified per-circuit in Blazor Server.

Old UI, unmatched depth. When dotnet-counters says 'memory grows' and gcdump says 'somewhere in here', PerfView tells you exactly where.

Async and memory anti-patterns with corrected examples, from the ASP.NET architect. Many 'Blazor is slow' cases are actually one of these.

The load infrastructure the ASP.NET team itself uses for TechEmpower runs. Steeper setup than k6, but it speaks SignalR.

Scriptable load testing with WebSocket support. Good for driving realistic SignalR connection ramps; pair scenarios with dotnet-counters on the server side.

Load testing in C#/F# that lets .NET teams write scenarios in the language they know, including against SignalR hubs with the real client library.

Managed option when you need geographic scale or CI/CD-integrated load gates without owning the injector fleet.

The annual deep-dive is the single best education in how .NET actually executes. Read the newest edition; skim earlier years for the cumulative picture.

The standard for micro-benchmarks. Use it to settle 'is this render path/allocation pattern faster' arguments with data instead of opinion.

Component-level rendering optimizations: virtualization, ShouldRender, event throttling. This is the per-circuit CPU/allocation side of the scaling story.

The community's index of Blazor libraries, tools, and articles. Broad rather than performance-focused, but the standard first stop.

The ASP.NET/Blazor standups are where roadmap and performance work get discussed months before documentation lands.

Release-cycle posts routinely include Blazor scalability changes (rendering modes, SignalR improvements) worth folding into capacity assumptions.