Remove two async state machines for typical HTTP/1.1 request path by stephentoub · Pull Request #58092 · dotnet/runtime

stephentoub · 2021-08-25T01:39:19Z

Rather than having a dedicated async method for SendAndProcessAltSvcAsync, we can just have the sole call site call DetermineVersionAndSendAsync and ProcessAltSvc. And in DetermineVersionAndSendAsync, special-case the default configuration for SocketsHttpHandler that will result in HTTP/1.1 messages being sent, such that we avoid all the tests for HTTP/2 and HTTP/3 and the async state machine for DetermineVersionAndSendAsync when HTTP/1.1 is being requested and used.

This doesn't entirely get us back to the allocation profile of .NET 5, but it's much closer.

Method	Toolchain	Mean	Error	StdDev	Ratio	Allocated
Request	\5.0.9\corerun.exe	56.43 us	0.829 us	0.735 us	1.00	1,416 B
Request	\main\corerun.exe	56.15 us	0.735 us	0.688 us	1.00	1,886 B
Request	\pr\corerun.exe	55.07 us	0.823 us	0.770 us	0.97	1,568 B

I also noticed an unused parameter to the HTTP/2 and HTTP/3 try send async methods, so I removed those as well, removing those parameters from the corresponding state machines.

Best reviewed without whitespace diffing: https://github.com/dotnet/runtime/pull/58092/files?w=1

Fixes#57977

ghost · 2021-08-25T01:39:22Z

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Rather than having a dedicated async method for SendAndProcessAltSvcAsync, we can just have the sole call site call DetermineVersionAndSendAsync and ProcessAltSvc. And in DetermineVersionAndSendAsync, special-case the default configuration for SocketsHttpHandler that will result in HTTP/1.1 messages being sent, such that we avoid all the tests for HTTP/2 and HTTP/3 and the async state machine for DetermineVersionAndSendAsync when HTTP/1.1 is being requested and used.

This doesn't entirely get us back to the allocation profile of .NET 5, but it's much closer.

Method	Toolchain	Mean	Error	StdDev	Ratio	Allocated
Request	\5.0.9\corerun.exe	56.43 us	0.829 us	0.735 us	1.00	1,416 B
Request	\main\corerun.exe	56.15 us	0.735 us	0.688 us	1.00	1,886 B
Request	\pr\corerun.exe	55.07 us	0.823 us	0.770 us	0.97	1,568 B

I also noticed an unused parameter to the HTTP/2 and HTTP/3 try send async methods, so I removed those as well, removing those parameters from the corresponding state machines.

Fixes #57977

Author:	stephentoub
Assignees:	-
Labels:	`area-System.Net.Http`, `tenet-performance`
Milestone:	6.0.0

geoffkizer · 2021-08-25T02:42:38Z

Should we keep #57977 open and consider other improvements, or do we think this is good for 6.0?

stephentoub · 2021-08-25T03:13:50Z

Should we keep #57977 open and consider other improvements, or do we think this is good for 6.0?

The changes in this PR seemed reasonable to me even without a goal of reducing state machines, i.e. I don't feel like we're sacrificing layering or factoring or anything like that. Beyond these two, though, it seems like we would have to make such choices, which makes me uncomfortable. I think we can live with the resulting 10% allocation increase over .NET 5 for this raw, do-as-little-as-possible benchmark. The moment you start doing anything more real, this won't matter. And if you start touching headers, .NET 6 is already way better.

That said, if you had ideas for getting rid of the SendUsingHttp11Async state machine (it's basically what remains now), I'd be interested.

There's also the option of using the pooling async method builder, but I think it's late in the game at this point to be exploring that here.

geoffkizer · 2021-08-25T03:17:57Z

We could just inline GetHttp11ConnectionAsync into SendUsingHttp11Async.

stephentoub · 2021-08-25T03:19:39Z

We could just inline GetHttp11ConnectionAsync into SendUsingHttp11Async.

Would you be ok with that? That felt like something you were trying to keep separate. But if you're cool with it, I'll add it to this PR.

geoffkizer · 2021-08-25T03:21:34Z

Would you be ok with that? That felt like something you were trying to keep separate. But if you're cool with it, I'll add it to this PR.

I think it's fine. SendUsingHttp11Async is not doing much currently aside from calling GetHttp11ConnectionAsync and then actually doing the send on the connection.

stephentoub · 2021-08-25T03:24:12Z

Oh, wait, that's not going to help. GetHttp11ConnectionAsync typically completes synchronously. It's SendUsingHttp11Async itself we'd need to inline, into SendWithRetryAsync.

geoffkizer · 2021-08-25T03:27:45Z

It's SendUsingHttp11Async itself we'd need to inline, into SendWithRetryAsync.

That doesn't seem crazy either.

stephentoub · 2021-08-25T15:07:53Z

It's SendUsingHttp11Async itself we'd need to inline, into SendWithRetryAsync.

That doesn't seem crazy either.

Inlining it would look like:
stephentoub@d93ed57
You're ok with that?

geoffkizer · 2021-08-26T00:00:13Z

You're ok with that?

I think so, yeah. It doesn't seem that ugly to me. I kind of wish we had a better name than "SendWithRetryAsync" now, since it's also doing the version determination... but I don't have a great suggestion. It's basically the main Send routine now (the only thing that happens before this is proxy auth) so perhaps we could call it SendAsyncCore or similar? I dunno. Thoughts?

Does this give a noticeable win vs previous changes?

I imagine we could do something similar here to get rid of a state machine for each of HTTP2 and HTTP3, right? Not super important at this point, but perhaps something to consider in the future.

That said, re HTTP3, I kind of want to refactor that a bit. Seems like some logic that's currently in TrySendUsingHttp3Async could instead be in GetHttp3ConnectionAsync, and the 421 retry logic could just be incorporated into our general retry logic. But none of that needs to happen for 6.0.

stephentoub · 2021-08-26T02:17:16Z

Ok, I think this is reasonable. @geoffkizer please take another look.

At this point, the simple scenario previously benchmarked is only 48 bytes more than .NET 5 (I could easily get it to 32 bytes by doing something unnatural I chose not to do).

Method	Toolchain	Mean	Ratio	Allocated
Request	d:\coreclrtest\5.0.9\corerun.exe	56.31 us	1.00	1,416 B
Request	d:\coreclrtest\main\corerun.exe	56.60 us	1.01	1,888 B
Request	d:\coreclrtest\pr\corerun.exe	54.84 us	0.97	1,464 B

geoffkizer

One nit re the assert, otherwise LGTM

geoffkizer · 2021-08-26T17:33:39Z

Also, let's run outerloop before merging.

geoffkizer · 2021-08-26T17:34:28Z

Is the plan to backport to 6.0 as is? If so I'm fine with that (assuming clean outerloop run)

stephentoub · 2021-08-26T19:02:53Z

/azp list

azure-pipelines · 2021-08-26T19:02:58Z

CI/CD Pipelines for this repository: coreclr-gc-longrunning coreclr-gc-simulator runtime-coreclr outerloop runtime-coreclr jitstress runtime-coreclr jitstressregs runtime-coreclr jitstress2-jitstressregs runtime-coreclr gcstress0x3-gcstress0xc runtime-coreclr gcstress-extra runtime-coreclr r2r-extra runtime-coreclr jitstress-isas-x86 runtime-coreclr jitstress-isas-arm runtime-coreclr jitstressregs-x86 runtime-coreclr libraries-jitstressregs runtime-coreclr libraries-jitstress2-jitstressregs runtime-coreclr r2r runtime-coreclr runincontext runtime-coreclr crossgen2 runtime-libraries-coreclr outerloop runtime-libraries-coreclr outerloop-windows runtime-libraries-coreclr outerloop-linux runtime-libraries-coreclr outerloop-osx runtime runtime-libraries enterprise-linux runtime-libraries stress-http runtime-libraries stress-ssl runtime-dev-innerloop runtime-coreclr crossgen2 outerloop coreclr-release-outerloop-nightly sync-runtime-to-mono runtime-coreclr crossgen2-composite runtime-jit-experimental runtime-coreclr libraries-jitstress dotnet-linker-tests runtime-coreclr ilasm runtime-coreclr crossgen2-composite gcstress runtime-libraries-mono outerloop runtime-staging runtime-coreclr pgo runtime-coreclr libraries-pgo coreclr-gc-regions

stephentoub · 2021-08-26T19:03:22Z

/azp run runtime-libraries-coreclr outerloop

azure-pipelines · 2021-08-26T19:03:37Z

Azure Pipelines successfully started running 1 pipeline(s).

stephentoub · 2021-08-26T19:04:35Z

Is the plan to backport to 6.0 as is? If so I'm fine with that (assuming clean outerloop run)

I'd like to, yes. I feel a lot better about an only ~3% increase in allocation than an ~33% increase in allocation, even for a minimal benchmark.

stephentoub · 2021-08-27T10:51:56Z

/backport to release/6.0

github-actions · 2021-08-27T10:52:10Z

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1173957232

stephentoub added area-System.Net.Http tenet-performance Performance related issue labels Aug 25, 2021

stephentoub added this to the 6.0.0 milestone Aug 25, 2021

geoffkizer approved these changes Aug 25, 2021
View reviewed changes

geoffkizer reviewed Aug 25, 2021
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs Outdated

ManickaP approved these changes Aug 25, 2021
View reviewed changes

stephentoub force-pushed the httpasm branch from 90a8e4c to 552cc59Compare August 26, 2021 02:08

geoffkizer reviewed Aug 26, 2021
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs Outdated

geoffkizer reviewed Aug 26, 2021
View reviewed changes

Comment threadsrc/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs Outdated

geoffkizer approved these changes Aug 26, 2021
View reviewed changes

stephentoub added 5 commits August 26, 2021 14:42

Remove two async state machines for typical HTTP/1.1 request path
f3c5866

Remove unused doRequestAuth parameter for HTTP/2 and HTTP/3
c50c663

Inline HTTP/1.x handling into SendWithRetryAsync
364391f

Inline HTTP/2 as well
4dd8ebe

Add back assert
e9e96f0

stephentoub force-pushed the httpasm branch from 552cc59 to e9e96f0Compare August 26, 2021 19:02

stephentoub merged commit 999e412 into dotnet:mainAug 27, 2021

stephentoub deleted the httpasm branch August 27, 2021 10:51

github-actionsBot mentioned this pull request Aug 27, 2021
[release/6.0] Remove two async state machines for typical HTTP/1.1 request path #58252
Merged

karelz modified the milestones: 6.0.0, 7.0.0 Aug 27, 2021

karelz mentioned this pull request Sep 6, 2021
Test failure: KeepAlivePingDelay_Infinite_NoKeepAlivePingIsSent #58724
Closed

ghost locked as resolved and limited conversation to collaborators Sep 26, 2021

Uh oh!

Conversation

stephentoub commented Aug 25, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Aug 25, 2021

Uh oh!

geoffkizer commented Aug 25, 2021

Uh oh!

stephentoub commented Aug 25, 2021

Uh oh!

geoffkizer commented Aug 25, 2021

Uh oh!

stephentoub commented Aug 25, 2021

Uh oh!

geoffkizer commented Aug 25, 2021

Uh oh!

stephentoub commented Aug 25, 2021

Uh oh!

geoffkizer commented Aug 25, 2021

Uh oh!

Uh oh!

stephentoub commented Aug 25, 2021

Uh oh!

geoffkizer commented Aug 26, 2021

Uh oh!

stephentoub commented Aug 26, 2021

Uh oh!

Uh oh!

Uh oh!

geoffkizer left a comment

Choose a reason for hiding this comment

Uh oh!

geoffkizer commented Aug 26, 2021

Uh oh!

geoffkizer commented Aug 26, 2021

Uh oh!

stephentoub commented Aug 26, 2021

Uh oh!

azure-pipelinesBot commented Aug 26, 2021

Uh oh!

stephentoub commented Aug 26, 2021

Uh oh!

azure-pipelinesBot commented Aug 26, 2021

Uh oh!

stephentoub commented Aug 26, 2021

Uh oh!

stephentoub commented Aug 27, 2021

Uh oh!

github-actionsBot commented Aug 27, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

stephentoub commented Aug 25, 2021•
edited
Loading