r/dotnet • u/blabmight • Mar 07 '21

Scalability differences between Blazor server vs Web Assembly?

Are there any metrics comparing the differences in scalability between Blazor Server vs Web Assembly? I keep reading that Blazer server is less scalable then Web Assembly but I haven't seen any raw data comparing the two.

14 Upvotes

80% Upvoted

29 comments sorted by

9

u/wasabiiii Mar 07 '21

Not sure you need metrics for this. Blazor server maintains a persistent session to the server, and the server holds all UI state.

We know what that does.

21

u/thankyoussd Mar 07 '21 edited Mar 07 '21

Microsoft says

Using Blazor Server at scale

Blazor Server can scale from small internal line of business apps to large internet scale apps. While .NET Core 3.0 was still in preview we tested Blazor Server to see what its baseline scale characteristics look like. We put a Blazor Server app under load with active clients and monitored the latency of the user interactions. In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency. A Standard_D3_V2 instance (4 vCPU, 14GB memory) handled well over 20,000 concurrent clients. The main bottleneck for handling further load was available memory. Will you see this level of scale in your own app? That will depend in large part on how much additional memory your app requires per user. But for many apps, we believe this level of scale out is quite reasonable. We also plan to post additional updates on improvements in Blazor Server scalability in the weeks ahead. So stay tuned!

So yes while Blazor server probably can't yet handle a super high traffic site at massive scale, it probably isn't that bad either for some other scenarios with the right setup.

Also, per this Github issue, MS does have plan to address Blazor server's scale-out scalability.

6

u/wasabiiii Mar 07 '21

Depends how you measure "super bad", I'd say. Are we talking on par with PHP? Because you can make PHP host thousands of concurrent users. But you can make something else handle 100s of thousands.

With modern CPU speed, you can literally get away with a site hosting tens of thousands of users with bash scripting that spits out HTML text. So we need something to compare it to.

2

u/DaRadioman Mar 07 '21

The same server requirement is really the thing that torpedos it for serious usage. 5-20K users isn't bad for a heavily interactive site such as an intranet or an enterprise app. But sticky sessions are really destructive to real scaling it resilient hosting.

1

u/thankyoussd Mar 07 '21

Do you think if Blazor server is used for something like an admin UI of a large app only, and an idle timer is implemented so that idle clients are automatically redirected to some non-Blazor page after X minutes, thus resetting their connection, the sticky session scalability will be less of an issue?

3

u/DaRadioman Mar 07 '21

For sure you could mitigate it, and that is a decent solution. Back in the days of Session State sticky sessions were the norm often times. It just makes upgrades a pain (have to bleed the users off each app server), and makes dynamic scaling (one of the big cloud benefits) much much harder.

All depends on your use case. If you don't expect lots of concurrent users, or don't need dynamic scaling, the it isn't nearly as much of an issue.

MS also offers some ways to store off the server state, which could potentially mitigate that completely of you could do so without a big performance impact. https://docs.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-5.0&pivots=server

1

u/reddit_time_waster May 01 '21

What's stopping me from throwing ever more instances in load balancing to scale further? Ex, I use the secure browser session storage (Blazored.SessionStorage)? Is there another centralized bottleneck?

1

u/herreruud2 Oct 17 '21

Nothing. The session they're talking about is just UI state, which will be recalculated. Doesn't matter.

4

u/blabmight Mar 07 '21

So Blazor server is going to be more taxing on the server? How much more taxing? More memory usage?

How different would the resource demands be with 10k concurrent connections?

With that I should be able to determine the cost difference hosting in Azure.

5

u/wasabiiii Mar 07 '21

Everything that is UI state is in memory on the server. So, yes. Every user who has the app open in consuming memory. Until they close the app. And then after like 20 minutes. It's like ASP.net session state on steroids.

Those users cannot roam between servers, or they lose their state. That torpedoes scalability and durability.

Memory usage depends on your specific app, of course.

5

u/MisterFor Mar 07 '21

For me that’s the biggest problem, that users can’t jump from one server to another and If the server restarts everyone loses their session. that’s a huge no-no for me.

5

u/puckhead78 Mar 07 '21

Yeah... this tradeoff should be significantly highlighted on the front page of the Blazor site/docs.

2

u/DaRadioman Mar 07 '21

Ya the server side model just isn't feasible for anything more than a small site unfortunately. It torpedos any enterprise usage with that requirement.

2

u/the_other_sam Mar 07 '21

In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency. A Standard_D3_V2 instance (4 vCPU, 14GB memory) handled well over 20,000 concurrent clients.

We don't know what these tests measure of course but unless Microsoft is deliberately misleading they seem at least adequate if not impressive.

The main bottleneck for handling further load was available memory.

MS was testing on servers with 3.5 GB and 14 GB of RAM. Configurations of 500GB or even 1TB are common.

It torpedos any enterprise usage

I don't understand how you reach this conclusion. Vast majority of companies are < 10,000 employees. But lets say we have an enterprise with 100,000.

Most internal apps in an enterprise are used by about 5% of personnel (pulled that out of the air based my experience). But lets say we we have 30% or 100k * .3 = 30,000 concurrent users.

MS test says 14GB ram supports 20k users or .00007 GB per user. Lets say our app requires 100 times more memory or per user or .00007 x 100 = .007 GB per user.

In theory if we had a machine with 1TB ram we could support (1000 / .007) = 142,857 concurrent users.

Yeah these are big round numbers but I think they should be well within the range of possibility for most enterprises.

2

u/MisterFor Mar 08 '21

And hosted on a single machine that if fails or has a hiccup everyone losses their session.

Explaining that failure to 20 persons it’s ok to 200, 2000 or 20000 is another story

2

u/DaRadioman Mar 08 '21

I highly doubt the scaling is linear, and I doubt MS tested with a large, enterprise application. I agree the numbers are decent on their surface, but I don't believe the real world would be as high. Either way though, my issue isn't with the raw numbers. It's with using that in an enterprise environment. You cannot have a server maintenance bring down 100,000 users. You cannot have a server upgrade reset even 10,000 users. Sticky sessions are an awful requirement that have rightfully died. It just isn't something you want in your architecture for any large number of users.

Not to mention that high powered app servers are expensive because they need to be fault tolerant, and load balanced, and geographically available. So instead of one expensive servers you need 6, and that gets prohibitively expensive quickly. Normal app servers don't need to be super powerful, so having lots isn't a big deal. Sticky sessions make scaling out difficult, and slow. They also make scaling down difficult without user data loss.

As I mentioned up above there are other options, like writing your own state persistence layer, but it just isn't ideal at all.

2

u/MisterFor Mar 09 '21

Those numbers are probably just for a ping or hello world application. They do the same with SignalR...

1

u/DaRadioman Mar 09 '21

Which makes sense. They want it to look rosy, and are showing a best case. Just can't trust them as real numbers for what a real world app would do. One of those things you have to test yourself based on your expected load.

0

u/the_other_sam Mar 09 '21

have a server maintenance bring down 100,000 users. You cannot have a server upgrade reset even 10,000 users. Sticky sessions are an awful re

Whatever happened to Reddis? And who says you have to have 1 box with 1TB - you can have 10 boxes with 100Gb.

It seems this line of reasoning is the tail wagging the dog. In most enterprises single points of failure are many. I am not convinced a Blazor server side app MUST be a single point of failure. What makes you think that it is? Load balancing and fault tolerance are common now, especially for cloud based architectures.

2

u/DaRadioman Mar 09 '21

And you just made my point lol. Sticky sessions are a huge cloud no no.

And Reddis doesn't store Blazor state... The ASP. Net server does. In memory.

If your designing an enterprise system with a single point of failure I am worried for your job. My boss certainly wouldn't look kindly on that sort of thing. I architect systems that people's lives depend on. Failure isn't really an option.

As I have said before there are ways to build in your own state persistence. But having to build it yourself (and with MS warning to do so sparingly) doesn't bode well.

Small non enterprise use, sure. Client side when it matures? Sure. But server side just isn't an attractive option with that requirement. It's web forms all over again lol.

0

u/the_other_sam Mar 09 '21

Literally four seconds on google got me this:

Server-side storage For permanent data persistence that spans multiple users and devices, the app can use server-side storage. Options include:

Blob storage Key-value storage Relational database Table storage

https://docs.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-5.0&pivots=server

This was possible way back in the day of asp.net web forms.

→ More replies

1

u/herreruud2 Oct 17 '21

No, you misunderstand what's meant by "session" here. It's UI state. It will be recalculated if you hit another server, or even if you refresh the page. Consider an alternative: Either react or Blazor WebAssembly.theu will keep UI state in browser memory. If you refresh, it will be lost. That doesn't matter unless the only place you store something important is in memory. Neither version of Blazor, nor react is designed that way. Only difference is the location on if the memory consumed holding UI state - the client or server.

2

u/MisterFor Oct 18 '21

What I refer as session in this case is mainly the web socket connection open between the browser and the server.

1

u/Federico86MO Nov 18 '21

Blazor server use SignlaR (based on Web Sockets)...and Web Sockets are not scalable.