For when Multiple ASP.NET Core Applications In Process per Application Pool ?

[hferreira]

I'm following .NET Core and ASP.NET Core since day one.

I have a huge .NET backend (ASP.NET Web Api) that I would like to port to .NET Core. Since version .NET 2.2 that my application is 100% compatible with both .NET Framework and .NET Core.

My first trials with .NET Core + ASP.NET Core + Kestrel + IIS was exactly 4.4 slower than .NET Framework + ASP.NET + IIS. The fun boys always tried to kidnap my arguments until In-Process model appears with the argument that is 4.4 faster (funny). Indeed it's not 4.4 faster, it's now exatly the same speed as .NET Framework + IIS in a real live world, so this long story suits to mention that the old model Out-Process it's not even an option.

My issue and it's currently the only think that stops me now to port to .NET Core is the absence of "Multiple ASP.NET Core Applications In Process per Application Pool" as we have with .NET Framework + IIS. .NET Core it's very near with .NET Framework that it's not there iet (for me) because of this.

I wished that this application indeed does not requires this option but it's not the case, so my question as the title mention is: For when Multiple ASP.NET Core Applications In Process per Application Pool ?

Thank you, Hugo.

[Tratcher]

There are no plans to add this feature. .NET Core lacks the AppDomain support needed to implement this. Can you clarify why you need it?

[hferreira]

I have a backend that is replicated several times. Each instance serves one direct client (that have is own sub-clients). There are dozens of applications that sharing the same app pool allowing to run with minimum server memory resources. If I change it, to one single app pool per client, I would need a super expensive server and will be a limit to grow.

I know that my options are:

1. Keep with .NET Framework 4.8 forever, though my code is currently 100% compatible with both .NET Framework and .NET Core;
2. Upgrade to .NET Core (ie just .NET in a year), if this requirement would be supported in a future version without impact on my current workflow => that would be great and I believe and there are clients with this requirement that don't allow to move to .NET Core;
3. Migrate my current solution to a multi-tenancy approach, however this would be a big challenge with the possibility to danger breaking changes and there are specific things per client that requires a more single-tenancy approach that will be hard to move to multi-tenancy approach.

Does are my reasons for this requirement.

There is any possibility to have .NET Core/.NET using the same App Pool in-process mode or a mechanism to share the memory (my reason for sharing App Pool) in a near future ?

[Tratcher]

Ok, it's about density and not any other functional issue. Can you give specific measurements showing the memory footprint with separate app pools, compared with your prior system that's sharing an app pool?

Yes, using a single app pool would allow sharing some memory, but mostly just for the dlls loaded, not the dynamic memory for running the app. I'm curious how much overhead that causes per instance that could realistically be shared.

There is any possibility to have .NET Core/.NET using the same App Pool in-process mode or a mechanism to share the memory (my reason for sharing App Pool) in a near future ?

.NET Core doesn't have the mechanics necessary for us to implement shared app pools (AppDomains and a shared GAC) and there are no plans to add them. As for other memory sharing mechanisms, I'm not aware of any proposals at the moment but we're open to ideas.

[analogrelay]

We should think about multiple apps per pool. We may talk about this in 5.0.

[hferreira]

@Tratcher My backend have more than 200 tables, using EntityFramework Code First.

Just for start, a single application on a single App Pool consumes surrounding 200 MB (from my past investigations, seems that EntityFramework it's responsible for a big share).

If I have 2 applications on separated App Pools, I will need 400 MB of RAM. I have about 40 applications and it's slowing growing: this will cost 200 MB x 40 Apps = 8 GB RAM (just for the applications, excluding OS and software peaks that consumes even more memory).

If I have 2 applications sharing the same App Pool, both will consume a little more than 200 MB! I have 4 App Pool for 40 applications (each one with 10 applications). A single App Pool running 10 applications at the same time, consumes around 500 MB (processing peaks grows to 1 GB and then slow than to 500 MB). So, 40 applications splited for 4 App Pools requires only 2 GB of RAM!

8 GB allows me to grow 4 times!

@anurse That's great news! You made my day :)

Thank you all for paying attention to this need and at least considering it for a future release. Have a great weekend and a great Christmas!

[hferreira]

Any news about this ?

[davidfowl]

No plans, it's not happening.

[SolidSoft-Lda]

It's a pity. The only thing that block us to move from .NET Framework to .NET Core/.NET

[jkotalik]

I think we will gauge interest in this feature and leave this open, however the cost for implementing is huge. I agree with David that this is most likely "not happening".