Oct 5, 2020
Welcome to Architect Tips with a tip so that you can get your team to move faster, deliver quality, and run your system with confidence!
We will talk about the architecture of Blazor and some of the key differences if you are running a Blazor application. Before we do that, you might wanna check out Azure DevOps Podcast; for .NET developers who are shipping software with Microsoft platform technologies; go to www.azuredevops.show.
However, it is important to understand what happens and that Razor component class is going to be on the call stack and is going to be alive in memory, that instance of the class, the entire time that screen is on the page, no matter how many times things are clicked, no matter how many times maybe a section of the page is swapped out, that is going to be on the call stack.
Now, if you do a navigate URL to another top-level page, well, then it will go out of memory and be cleaned up. That is how Blazor server-side works. Every session, every user’s screen, and what a user is doing is resident in memory on your web server, and the changes to the screen are messaged through that SignalR hub with binary messages. So, what is important is the latency in the network connection. If you have really bad latency, then your users are going to see slowness. For instance, if you have 100-millisecond latency, you may need 10 round trips to the server, which is not unheard of, these messages are really small, but if it is 100 milliseconds of latency with each one, well, that is one second. So you have to keep that in mind, that is the architecture.
Let's now go over some of the settings. When you are publishing to Azure, you will want to make sure that you choose 64 bit because you will be using up more memory. Every one of your agents, every one of your users, keeps that memory on the server and their session, everything they do, and all of the memory keep those objects on the webserver. You will be using more memory as a trade-off for that phenomenally fast development model.
You can also press F12 in the browser tools and make sure that you’re connected to your WSS protocol for the web socket. You also want to have ARR Affinity because we keep around in-memory objects for user sessions; you want to make sure that essentially you are turning on sticky sessions.
The first request comes in, a user will be assigned by the load balancer to one of your web instances, and that user will use that web server instance the whole time they have that tab open for that session.
They may be assigned to a different one if they close the browser tab and come back and essentially recreate everything from scratch, but you’ll be on one web instance.
You can inspect all the different frames coming that are coming just by looking at the performance tab in the Chrome developer tools. It is really important that you understand how many frames are necessary per page because if you have a ton, it will make for a slow page. So, you want to use that as a point of optimization.
You will also want to look at how many round trips your application is making to the server. You can go to the network tab in the tools, and you can click on the web socket connection, and you can see all these different binary messages. If you select one, you can see what it is doing at every stage, every message that’s called a round trip. We can see the OnRender completed right here, and I have zoomed in on the bottom.
You will want to inspect that and understand what your message is doing with these binary messages. Now, the Canary version of Edge, the Chromium version of Edge, has some enhancements that are being worked on in the developer tools to show a visualizer of these binary messages so that you can sniff the wire and you can see exactly what is coming through. Right now, it is not very helpful to see the current views other than it came through and how big these are, but the tooling is coming so that we can see exactly what is in these messages because that will be important.
When you are running an Azure, you want to have a minimum of two web instances. Because it uses sticky sessions, and if something happens to that web instance, you want the web browser to immediately be able to take all of the connected sessions and move them to another instance of the webserver.
I hope that helps and if you are starting a Blazor project, let us help you avoid those pitfalls. Clear Measure is a software architecture company that really wants to help your development team move fast and deliver quality and run your systems with confidence so that you can get more done internally within your team and deliver world-class results. Thank you very much, and that was another Architect Tip.