ctx.RequestAborted in a trace surfaces many Dictionary.Resize calls

[NinoFloris]

Feature collection initializes the inner dictionary without a capacity, after the first insert this would mean it grows to 3 (due to prime based capacity growth).

aspnetcore/src/Http/Http.Features/src/FeatureCollection.cs

Lines 74 to 78 in 1c8da41

	if (_features == null)
	{
	_features = new Dictionary<Type, object>();
	}
	_features[key] = value;

What we're seeing in traces is that we have a lot of pointless resizing as the framework and users use certain features on every request leaving no capacity to grow without resizing, for us this is:

• HttpRequestIdentifierFeature (when scopes are enabled this gets logged by the framework)
• RequestServicesFeature (we set our own on every request due to multi-tenancy, but framework would too either way)
• ItemsFeature (there is some state passing here)

Which means we're already at 3 without really doing anything special.

Now when we access ctx.RequestAborted, which we do only on certain requests, this triggers a resize to fit the HttpRequestLifetimeFeature. (this could just as easily have happened by doing auth, which we do on other requests, or accessing session or some other _features backed HttpContext properties)

If we can agree on the initial set not doing anything particularly uncommon, would it then make sense to initialize the dictionary with a capacity slightly larger than 3? For Dictionary this would mean it would resolve to capacity 7 which I believe is much more comfortable for most aspnet core uses.

[davidfowl]

What server implementation is this?

[NinoFloris]

Kestrel with DefaultHttpContext

[davidfowl]

Doesn't make sense. Kestrel doesn't use this implementation of the FeatureCollection.

[NinoFloris]

I see, let me try and find the right one then. I've been doing github spelunking starting from DefaultHttpContext

[davidfowl]

I say this because there's literally no dictionary https://github.com/dotnet/aspnetcore/blob/85a6cb07ae2e1adf5a03740f8d40333b7b8e360c/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.Generated.cs.

There's a list for unknown features but this is a known feature...

[NinoFloris]

Ah right it's the codegenned unit, do the custom ones end up in MaybeExtra with an initial capacity of 2?

Either way, going to look again where the Dictionary.Resize is coming from, could it be the Items dictionary itself? (this trace is massive, I get lost in the stack depth)

I'll update my opening comment if I still think there's anything actionable, otherwise I'll close.

Thanks for the quick replies!

[NinoFloris]

Looking at it again from the backtrace I really do see the FeatureCollection pop up, yet I'm certain we use Kestrel, how can this be? We're on .net 5.0

EDIT:
We're newing up a DefaultHttpContext() to push certain synthesized values through our tenant stack from an internal api endpoint that allows us to fetch any tenant, as our tenant resolution code is normally called in cases where the request is in a certain shape we massage a new HttpContext into that shape so we can move on. At some point this code also accesses that new context's RequestAborted which causes the resize. (and that token will never trigger, which is another issue)

So culprit found, I think it may still be helpful to change the FeatureCollection initial capacity from 3 to 7 but it's not a problem for actual http requests!

@davidfowl what do you think? (I will make a PR right away if you think it's not a bad change) otherwise I'll close!

[davidfowl]

We just need an API suggestion to allow specifying the capacity instead of hardcoding it.

[NinoFloris]

Done #31249