Yes, Blazor Server can scale!


From the very beginning of the release of Blazor Server naysayers have incorrectly stated that Blazor Server can not scale.  They usually state that the limit is 5,000 concurrent users.

There are several misconceptions and wrong assumptions about their statement.  Let's break it down and get a better understanding of Blazor server-side scaling.


What is the "limit" for users

When Microsoft talks about the need to scale an application, what they are saying is that when a normal response for any concurrent user is taking longer than 200 ms, the system is not performant and needs to scale.

We will accept that definition:

If any normal user response is taking longer than 200 ms, the system needs to scale for concurrent users.

By a normal response, we are referring to a page get, a post, etc.  Large database access requests would not be included in this measurement.

What is scaling

There are 2 common ways to scale, scale, out horizontally, and scale-up, up vertically.

In our discussion, we will scale within these normals.

Scale Vertically

Scale vertically means adding more computing and/or memory to the machine.

In our example, Microsoft has stated that a 1-core, 3.5 GB memory machine can scale to 5000 concurrent users.  

Note this is for concurrent users, not total users.  So if you have a system with 10,000 users, but you have only 1000 on at any given time, you are fine with the machine listed above.  By the way, you should know how many concurrent users you have using your system over any given day.

Upgrade your Azure machine to the P2V3, 4 Core, 16 GB memory, and you can support up to 20,000 concurrent users.

For a single Azure app service, your application can support up to 20,000 concurrent users.   That seems fairly decent.

Scale Horizontally

Scale horizontally means adding more machines.  This is where Blazor Serverside gets a touch more complicated.

1. Blazor Serverside uses SignalR to communicate with the server

2. That instance of SignalR is actually executing on the server that the Blazor application is running from.

3. The Blazor application needs to be able to talk to the machine that it was launched from.

Each of these constraints can easily be solved.

1.  Create and use the Azure SignalR hub service.  This service will be responsible for the routing of the SignalR connections to the correct physical machine.  This service runs from its own set of servers, thus removing the overhead from the Blazor App service.  This change resolved items #1 and #2.

2. Item #3 is commonly referred to as "sticky" sessions.  This feature is actually already available within the App Server.   Under App Service Configuration => General there is a setting called "ARR affinity".  By turning this on, you will enable sticky sessions.

With the changes above, we can now add as many app services to our solutions.  This will also allow us to set up Azure autoscaling.

At this point, we have actually hit a limitation.  With the Azure SignalR Service.  As of this post, the maximum number of SingleR connections a service can have is 100,000 concurrent connections.

Thus there is a limit of 100,000 concurrent users to a Blazor Server Side application.

I don't know about you but seems scalable.

Uber Scale

If you are building an "uber" scalable site like Stackoverflow, Slack, Twitter, etc., your application will need to scale to millions of users.  That would be beyond what a Blazor Application could handle with normal architecture. 

Cost

Hopefully, you would agree at this point, that we can scale a Blazor Serverside application.  

Let's talk about the real limiting factor of scaling, money.

We will use supporting the 100, 000 user example.  This is what we will need:

1. SignleR Service

    Estimated Cost:

    100 units X 1 month X 0.0671 = $4,894.08

2. 5 4 Core, 16GB app services.

    Estimated Cost:

    5 X 1 Month = $2,445.50

You are looking at a total cost of $7339.58.

Compare that to the cost of $0.00 for a CDN plus the cost for your API, maybe a single App service, $489.10

Only your business model will be able to tell you if that is justified for you.


Summary

The key takeaway from this post is that you should not limit your solution options based on what you hear.   Do some research, and know the constraints you will be dealing with for your application.  

We only talked about concurrent users and cost.  there are a lot more factors you should evaluate before making a decision.

Blazor Serverside applications are the right solution for many applications.

Comments

  1. Replies
    1. Thank you for sharing your investigation. Extremely helpful!

      Delete
  2. So true :) Thanks

    ReplyDelete
  3. Any tips for scaling when you are NOT in Azure? (We have our own self-hosted web farm - what is the self hosted equivalent of the signal R service in Azure?)

    ReplyDelete
  4. Take a look at Blazor in .Net 8. It allows you to mix server and web assembly and it does not really so weighty on SignalR as in previously releases. Also if you have less than 5000 concurrent users, any server should be able to work.

    ReplyDelete

Post a Comment

Popular posts from this blog

Blazor new and improved Search Box

Blazor Wizard Step Component