Make sure IHttpContextAccessor is always registered

[dotnetjunkie]

The IHttpContextAccessor allows access to the current executing HttpContext and seems to be a core component of ASP.NET. Still however, the IHttpContextAccessor is not registered by default by ASP.NET while it IMO definitely should.

The whole idea behind the new configuration model in ASP.NET is that everything is registered for you magically behind the covers, but even if you call AddMvc or even AddMvcCore the IHttpContextAccessor isn't registered, while there are many integration scenarios that require its availability. This means that 3rd parties (or possibly even future framework components) always need to check its availability and throw an exception when it's not registered and application developers always need to register it manually.

[davidfowl]

The whole idea behind the new configuration model in ASP.NET is that everything is registered for you magically behind the covers, but even if you call AddMvc or even AddMvcCore the IHttpContextAccessor isn't registered, while there are many integration scenarios that require its availability.

Not everything, everything that is required. We did extra work to make sure that our own types don't rely on it (because ambient state is bad and hard to reason about).

One of the reasons we took it out for performance. We don't want every ASP.NET application to enable execution context copies (what happens as soon as you use async local). Also, we don't really want users to use this type unless they need it.

This means that 3rd parties (or possibly even future framework components) always need to check its availability and throw an exception when it's not registered and application developers always need to register it manually.

Add it if you need it in your services. That's the pattern we use. https://github.com/aspnet/Identity/blob/ee83dfe9be3dc17fa8367a0031ff355392db8a76/src/Microsoft.AspNetCore.Identity/IdentityServiceCollectionExtensions.cs#L54

[davidfowl]

Though to be honest, if nobody resolves it, there should be no cost. We did all of the hard work to decouple ourselves from it so maybe it's ok to add it to hosting.

/cc @rynowak @Tratcher

[benaadams]

If you register it then HttpContextFactory will resolve it and set the AsyncLocal to the HttpContext; which means every await and dispatch to threadpool is no longer on the default execution context fast path.

[dotnetjunkie]

One of the reasons we took it out for performance.

I find it hard to believe that the use of such ambient state will actually cause any detectable performance hit. Especially with all the I/O going on. Have you actually measured this and publically described this somewhere what the performance impact is?

we don't really want users to use this type unless they need it.

I don't believe that adding this by default will cause users to automatically use it. I just think that not adding it by default will simply cause users to add it by hand.

because ambient state is bad

Apparently not that bad, because ASP.NET uses it for logging scopes.

every await and dispatch to threadpool is no longer on the default execution context fast path.

Since everybody uses logging in their application, doesn't this mean that we never run on this context fast path?

[benaadams]

because ambient state is bad

Apparently not that bad, because ASP.NET uses it for logging scopes.

Only ConsoleLogScope alters the execution context in this way; and if want high throughput you shouldn't be really using that in production as then your entire app is gated on one global lock in Console if you log anything.

[davidfowl]

Ah yes that was the problem with turning it on by default. We need to resolve it ourselves to set it. It needs to be added by the components that need it.

[davidfowl]

I find it hard to believe that the use of such Ambient Context will actually cause any detectable performance hit. Especially with all the I/O going on. Have you actually measured this and publically described this somewhere what the performance impact is?

Yes, @benaadams measured it as part of our benchmarks runs and it was significant. Scoped logging does tend to use async local as well so the cost might be incurred there depending on the logging system. These things are fine, they just can't be all on by default.

[dotnetjunkie]

Yes, @benaadams measured it as part of our benchmarks runs and it was significant.

Can you link to his benchmark results?

[davidfowl]

This was the change that disabled it.

• First the benchmark - aspnet/Benchmarks@909a929
• Officially removed- Set IHttpContextAccessor only if DI provides it #475

Can't find any performance numbers on the repo but you might be able to the differences in the excel spreadsheet in the Updated Results commit after the change:

https://github.com/aspnet/benchmarks/commits/dev?after=G6n%2FgPpHkWvHSt0NmAuyU1ZqXqIrMTM5

[benaadams]

Have you actually measured this and publically described this somewhere what the performance impact is?

aspnet/Hosting#330
aspnet/Hosting#356

On 4.6+ it allocates 680k per 2000 requests and creates an additional 2 dictionaries per request.

Every await that is async allocates an additional 8 bytes dotnet/coreclr#3157

When the HttpContext is set ExecutionContext.SetLocalValue is additionally run

[benaadams]

You don't normally need to use IHttpContextAccessor as DI will inject the HttpContext for you if you ask for it; and then is scope is more controlled (as you shouldn't be using it outside of a request)

[davidfowl]

You don't normally need ambient state. It shouldn't be the default way of doing things. This is an optional convenience for people. Unfortunately it's required to get the scoped service provider for scenarios like this aspnet/Mvc#5403

[davidfowl]

Moar perf numbers - aspnet/Mvc#3523

[dotnetjunkie]

What I see is that the there is especially a perf hit under .NET 4.5.1 where there is no optimized AsyncLocal. Besides that, we will see the improvement be deminished when any I/O is done. But since this optimization is a very conscious action, I understand that you won't go to the 'default on' scenario. It's unfortunate though that this makes less intuitive for non-conformers.