The Razor components are going to stream over web sockets for any changes that need to happen to your screen. So, as you look at your development tools in your browser, you are going to see a bunch of binary messages going across; those are the actual changes to your screen and that is the communication.
Now, if you’re running in Azure and you are running with multiple instances and you have some custom auto scaling rules, which you’re going to want to do, and you’re going to want to custom auto scale, then you are going to have the question: How many of the users are tied to or how many of the connected circuits are tied to each of the web servers?
Because you are going to be using sticky sessions; that is the ARR Affinity as Azure calls it. And, once a user gets assigned by the load balancer to a particular web server instance in your app service plan, it is going to stay there for the life of the session, which is the circuit.
Are Your Instances Overloaded?
So, you are going to want to know, what is my distribution? Do I have one that is overloaded?
If you scale up, that does not cause the user sessions to be more evenly distributed. Once a user is assigned to an instance, it is there. You can scale up after the fact, but that is only going to affect new users that come in after you have scaled up.
If the original instances are overloaded, they are going to remain overloaded unless you do something to force the closure of those circuits. Then you can have the auto-retry logic on the client side to help with redistribution. So, what you are going to want is a graph in your dashboard and application insights that looks like this:
On the top-right you can see average open circuits. Then bottom-left, you can see the average connected circuits. On the bottom-right is how many circuits have disconnected over time. Then it is often also good to track the memory of each of the instances of your application; we can see that on the top-left in this example.
Blazor Circuit Handler Class
You do not get this out of the box, so you are going to need to emit some custom metrics, to application insights. I’m going to show you how to do that with Blazor server side. There is a class in Blazor called circuit handler, and you can find it in …
In .NET 5, that is going to be really easy to find a refactored with .NET 3.1.8 you are going to find that in the components.server.webassembly nuget package. You are going to have to grab the WebAssembly nuget package to get something specific to, Blazor server side. But that is where it is.
You’re going to inherit your own class from this, register it in your services collection, and you can do with it, whatever you want, because you’re going to get events for circuit up and down. Look at what we’ve done here: we’ve created the names of the different events and we’ve created a dictionary for open circuits. Then a timer so we don’t emit this metric every single time it fires.
Blazor Circuit Tracking Events
Then the events that you get are circuit opened and circuit closed. Look at that with circuit open, it is going to be called for us by the framework. In our dictionary, this circuit is open using a dictionary. We make sure that we do not have duplicates. Whereas we found in real practice that these events, get called and fired, are not completely synchronous.
So, you will want to use some type of hashing, mapping or dictionary, deduplication, but just using a dictionary works just fine. So open circuits, that is our logic there. You could use a simple int counter, whatever logic you want. Then, you get the opportunity to do something when the circuit opens and when the circuit closes. You also get events that are correlated on connection up and on connection down.
We do the same thing with the dictionary, on those things. So that is your tip. That is your architect tip for, Blazor server-side connection tracking. It is going to be important as you get your applications into production to know how many open circuits you have per web instance and what your traffic is overall. So, I hope you enjoyed this architect tip.