with blazor server, the hub is the connection. both the server and the browser are signal/r clients, using the hub to communicate. to scale it makes sense to move the hub to dedicated servers.
as azure signal/r hubs scale, it your choice to share or use multiple hubs.
if your blazor server code is also using signal/r to talk to other services, then the dedicated server thread for the blazor app, has multiple signal/r client connections.
not sure what you mean by web app to handle signal/r load
you can log the messages for a blazor session. every browser event that your blazor code attaches to, requires the js code to send a signal/r event when that event occurs in the browser. avoid keyboard and mouse events.
every component render updates the blazor tree (blazer version of the dom). all blazer tree updates must be sent to the browser over signal/r. optimize component re-render. you do this by keeping state as far down the component tree as possible. you don't want to re-render a parent component just to render one of its children.
if you are scaling blazor server, you need to scale the signal/r hub. azure signal/r has easy scaling, or you build you own. to build your own, you will probably need a load balancer with sticky sessions. to build you own, you probably want the blazor server to host the blazor signal/r hub. the load balancer then then pick blazor/hub server, and the sticky session would allow a reconnect.
blazor server requires signal/r to talk to the client code in the browser. whether to use signal/r for additional events is your choice.
the blazor server code is running as long as the user has the app loaded in the browser. if like me, they leave tabs open to sites for days, you server code (thread/state memory) dedicated to that tab will be running for days. if this is an issue, than you will probably need a watchdog timer to shutdown the app.
blazor server scaling is much more expensive then blazor WASM or a classic web app (even one that uses signal/r).