Remove stateful prerendering

[rynowak]

Summary

Blazor has a feature that I'll refer to as stateful-prerendering where you render a group of components on the server, and then retain that group of components in memory until the client opens a SignalR connection (or it times out).

This currently has some really bad scalability problems, and we think it's not viable for use in production with the current implementation.

However, this is a nicer developer experience than some of the alternatives because a variety of different scenarios just work.

I'm sure that if we had lots of time we could provide a set of complicated knobs and dials that developers could use to try and make this feature viable for their use case and risks, we're out of time to do so. The extra things that stateful-prerendering enables are not on the main path for server-side Blazor, and so it should be cut entirely.

Proposed Template Changes

These changes should take place in Preview 8 so that we can gather feedback

We'll use a different technique to wire up the entry point component in the template.

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapBlazorHub<App>(selector: "app");
                endpoints.MapFallbackToPage("/_Host");
            });

We'll still use prerendering in the template, but we'll call out how to remove it.

    <app>
        @* Remove the following line of code to disable prerendering *@
        @(await Html.RenderStaticComponentAsync<App>())
    </app>

See notes below about RenderStaticComponentAsync

Proposed Product Changes

These changes can take place as late as Preview 9 - but earlier is always better

We should remove the functionality for stateful-prerendering from the server. We're not recommending it for use in any production scenario, and so we should remove the functionality.

The Microsoft.AspNetCore.Mvc.Components.Prerendering package can be removed.

The RenderStaticComponentAsync methods should be renamed to RenderComponentAsync.

Various implementation pieces can be cleaned up as-desired. We can't predict right now if we'll bring back the same feature in the same way, so the cleanest thing to do would be to remove all of the unneeded functionality.

[SteveSandersonMS]

Note that as a prerequisite to making these changes, we also have to fix #11799, otherwise the template will be broken by default.

[javiercn]

Can we put the appropriate supporting data that showcases the concerns we have in this issue for future reference in case we want to bring the feature back at a later point?

[rynowak]

Sure - @pranavkm

[chrdlx]

Will this affect the way we embed blazor components in MVC/Razor Pages?
I'm building an enterprise web portal with razor pages, and for the interactive parts I went for blazor components embedded in them , will I be in trouble with this change?

Regards

[rynowak]

Will this affect the way we embed blazor components in MVC/Razor Pages?

Yes, it won't be possible to pass parameters into the top level component and have it retain state. So you can definitely host interactive widgets on pages - but it won't be straightforward to pass data in.

[chrdlx]

Will this affect the way we embed blazor components in MVC/Razor Pages?

Yes, it won't be possible to pass parameters into the top level component and have it retain state. So you can definitely host interactive widgets on pages - but it won't be straightforward to pass data in.

Oh ok, so if I understood correctly, from the docs:

https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.0#integrate-components-into-razor-pages-and-mvc-apps

@(await Html.RenderComponentAsync<Counter>(new { IncrementAmount = 10 }))

This won't be possible anymore and there will be another way to pass that parameter to the components?

Also, is fine to answer this kind of questions here or am I polluting the thread?
Regards

[rynowak]

@(await Html.RenderComponentAsync<Counter>(new { IncrementAmount = 10 }))

Right. This is what I'm saying will be removed. We haven't created another way to pass parameters into components for 3.0.

The problem is that this relies on creating the Counter component while the request is happening, and keeping it around in memory until some time in the future when the browser connects back.

We've been doing measurements of this and it's going to be really hard to run in production without problems - if you have untrusted clients, they can force the server to do a lot of work or keep a lot of things in memory.

Also, is fine to answer this kind of questions here or am I polluting the thread?

Perfectly fine. If you want to give us some examples of things you're trying to do we can try to provide more information or ideas.

[pranavkm]

Here are my notes from when I ran this on the Benchmark server:

---

1. I was using our default template as the application + preview7 bits
2. Clients attempt to DOS by attempting the exhaust the disconnected circuit buffer. To do this, they do a HTTP GET on the home page. This triggers our pre-rendering
3. I used the benchmarking infrastructure. It has workers that support performing a constant RPS over vanilla HTTP
4. I used a browser to verify that the app was still functional while being DOSed. It’s not a very scientific way to test, but it was good enough for our needs.

With the size limit that we have by default, the site’s immediately unusable. Reconnects consistenty fail and the build logs filled with stuff like this:

[40m[37mdbug[39m[22m[49m: Microsoft.AspNetCore.Components.Server.Circuits.CircuitRegistry[111]
      Circuit with id CfDJ8F_JmI3ECwpDqUv08g88IdLWucBmdKhe4nUGPqlyXvASEQXyuTM_3KU27VBAdLIwiOGULRO-2asWRPzFvdQDGDU8D-JRj1i7ikj-BPbEXGHhTN0F4v4r2UGctcdkF5QHm0rWiZ4HIT5TMua-i1P7TzC4rZ3ssA9RhTkN4IVGkvm4 evicted due to Capacity.
[40m[37mdbug[39m[22m[49m: Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost[105]
      Closing circuit with id CfDJ8F_JmI3ECwpDqUv08g88IdKW7WSP3Vj9OyXXP0HJctvy2guLEn3bhnFBVIngaxnPtLHA4MKF8SjG1rLnNL7bUCDsP-eaeoVg-8tRrqoh4Ng1s8DD1O-rEhdvcXwCHUTMqI3mI_oyiBlWA5W0TQrB8ZUCEhcWn3yBaAklWdsab5zy.

Ryan suggested removing the size limit entirely (set to int32.MaxValue) and that does make the application way more usable. I played around with different timeouts and RPS values to see what the app looks like.

Here’s one set of data points:

500	30	RequestsPerSecond:           852
Max CPU (%):                 21
WorkingSet (MB):             471
Avg. Latency (ms):           6.42
1500	30	RequestsPerSecond:           14,296
Max CPU (%):                 76
WorkingSet (MB):             3,975
Avg. Latency (ms):           21.13
3500	30	RequestsPerSecond:           7,961
Max CPU (%):                 99
WorkingSet (MB):             4,624
Avg. Latency (ms):           116.42

Approaching higher RPS, the working set tends to be really large. To test that this is primarily coming from pre-rendering, I tried out what it looked like with static pre-rendering:

500	RequestsPerSecond:           902
Max CPU (%):                 17
WorkingSet (MB):             182
Avg. Latency (ms):           6.73
1500	RequestsPerSecond:           2,995
Max CPU (%):                 65
WorkingSet (MB):             193
Avg. Latency (ms):           7.27
3500	RequestsPerSecond:           7,744
Max CPU (%):                 101
WorkingSet (MB):             187
Avg. Latency (ms):           96.89

Effectively for a small amount of work that the client performed (make a HTTP GET request) the server would allocate a ton of memory waiting for the client to reconnect. By spamming the server with GETs you could effectively DOS the server or require that the server preserve a really large amount of state to guarantee the reconnect succeeds.

[javiercn]

A couple of thoughts for the future I guess.

• Does the memory goes back down once you stop sending data to the client?
• If we were to avoid having a limit on prerendered circuits (we special case them, by putting them on a special queue and getting rid of them after lets say 5-10 seconds after we start sending the response to the client).
  • Does the memory growth slow down significantly?
  • Does the memory growth go back to normal after the 5 to 10 seconds? (Meaning we don't hold on to any reference after that).

While the memory grows here by a lot, I think the scenario is similar to a client dispatching events at a high rate, in the sense that the memory grows and then goes back down after there is no more work happening.

One thing we could consider is to have the feature not be on by default and provide good documentation about its usage. There are environments where this feature is very valuable and this threat (if anything) is not a problem, like intranet applications.

[jzabroski]

While the memory grows here by a lot, I think the scenario is similar to a client dispatching events at a high rate, in the sense that the memory grows and then goes back down after there is no more work happening.

Interesting. That is what Streambase does: they kick out of the queue all the clients that are too slow to connect to the CEP stream and consume the events. Their "queue" is actually LMAX Disruptor design pattern. Performance is then relative to fitting the ring buffer in the L1 cache. If the ring buffer cannot fit in the L1 cache, then it becomes a bit like having an empty beer fridge in the living room, and having to go to the kitchen for refreshment during the Big Game.

Is LMAX Disruptor a usable design pattern for mainstream programmers, though?