Blazor Server circuit retention vs. client reconnection timeout for flaky networks

Scenario

I'm designing a Blazor Server app (assume .NET 8) where users on unstable mobile connections intermittently lose the SignalR circuit. The documented knobs are server-side circuit retention (DisconnectedCircuitRetentionPeriod / DisconnectedCircuitMaxRetained) and the client-side reconnection behavior configured via Blazor.start({ reconnectionOptions }) or the default reconnection UI.

The trade-off

A longer retention period preserves component state so users resume seamlessly after brief drops, but retained circuits consume server memory per disconnected user, which matters at scale. Conversely, aggressive client reconnection attempts with short retention free server resources quickly but force users through full circuit re-creation and state loss more often.

It's unclear to me how these two settings interact in practice: whether the client gives up before the server retention window matters at all, and whether retained-circuit memory pressure is significant enough to justify shortening retention on a memory-constrained host.

Questions

• Should the client's maximum reconnection window be tuned to match or stay shorter than DisconnectedCircuitRetentionPeriod?
• Is there a documented way to measure retained-circuit memory usage to size DisconnectedCircuitMaxRetained?
• For stateless components, is short retention with fast re-creation generally preferable to long retention?