Kestrel should implement IHttpRequestIdentifierFeature to avoid the slow default implementation

[AspNetSmurfLab]

Perhaps use the socket handle ID combined with a simple counter of some sort. Make it as "free" as possible 😄

by @DamianEdwards

[Tratcher]

We also need this in order to take full advantage of the static feature collection from #162

[davidfowl]

I actually think we should make the default implementation not slow 😄

[AspNetSmurfLab]

FYI, CPU profile of latest Kestrel showing that this is currently the most expensive item in the plaintext benchmark, accounting for 7.17% of all CPU time.

by @DamianEdwards

[AspNetSmurfLab]

Trying to make the default implementation in Hosting faster first: https://github.com/aspnet/Hosting/tree/damianedwards/fast-request-id

by @DamianEdwards

[muratg]

@DamianEdwards Link to your branch on hosting doesn't work. Is that merged or deleted?

[davidfowl]

Hosting has a very fast implementation that is already merged now.

[muratg]

So this one good to close, or do we plan to do more on Kestrel to gain more perf?

[Tratcher]

Kestrel could still do better than Hosting, such as #243

[benaadams]

Or can push up to HttpAbstractions and add TraceIdentifier onto HttpContext which then makes it available for wider use aspnet/HttpAbstractions#435

Then switch to lazy eval? aspnet/Hosting#394, no change in Kestrel, all aspnet servers go faster.

[muratg]

Not sure if this is still relevant. @DamianEdwards feel free to close.

[sajayantony]

@halter73 wanted to get pulse on this issue. Is it still relevant or did you break it into some other issue.

[halter73]

I'm closing this issue. Feel free to reopen, but since the time this issue was filed, the default IHttpRequestIdentifierFeature was changed to both lazily evaluate the request identifier and cache the result. I don't think there's anything about generating the identifier in Kestrel itself that could really make this faster.