Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add inline scheduler option for Sockets transport #24638

Merged
merged 5 commits into from
Aug 18, 2020

Conversation

BrennanConroy
Copy link
Member

Fixes #20952

Sockets Default + Kestrel Default : 1,187,598 RPS
Sockets Inline + Kestrel Inline: 1,242,924 RPS
Sockets Inline + Kestrel Default: 1,072,542 RPS
Sockets Default + Kestrel Inline: 1,153,500 RPS

@BrennanConroy BrennanConroy added area-servers feature-kestrel api-suggestion Early API idea and discussion, it is NOT ready for implementation labels Aug 7, 2020
@BrennanConroy BrennanConroy added this to the 5.0.0-rc1 milestone Aug 7, 2020
/// <remarks>
/// This will run application code on the IO thread which is why this is unsafe.
/// </remarks>
public bool UnsafeInlineScheduling { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RunOnTransportThread

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't sound unsafe enough!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UnsafeRunOnTransportThread!

Copy link
Contributor

@pranavkm pranavkm Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public bool UnsafeInlineScheduling { get; set; }
public bool UnsafePreferInlineScheduling { get; set; }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • We add the API and get the API added in dotnet/runtime. Setting our API should set both.
  • We add the API and We use private reflection to set it on the socket itself. Setting our API should set both.
  • We don't expose a public API and we also consume the env variable. (and we have an opt-out for weird cases)

Copy link
Member Author

@BrennanConroy BrennanConroy Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the env variable in Runtime globally affects some settings and even if you use private reflection to set the per Socket setting you don't affect the other things the env variable does. This results in massive perf regressions, i.e. 100k RPS without the env variable but with private reflection vs. 1.2M RPS with the env variable and no private reflection.

https://github.com/tmds/runtime/blob/6ea1256bf8bd9ce6c1db278603b332cec144ba75/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs#L26

@davidfowl davidfowl added the api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews label Aug 7, 2020
@ghost
Copy link

ghost commented Aug 7, 2020

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

  • The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
  • The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
  • Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

@davidfowl davidfowl removed the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Aug 7, 2020
/// Inline application and transport continuations instead of dispatching to the threadpool.
/// </summary>
/// <remarks>
/// This will run application code on the IO thread which is why this is unsafe.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explain how this can hurt your performance. Also document the DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS environment variable.

@pranavkm pranavkm added api-approved API was approved in API review, it can be implemented and removed api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews labels Aug 10, 2020
@BrennanConroy BrennanConroy changed the base branch from master to release/5.0 August 17, 2020 21:40
@BrennanConroy
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@BrennanConroy BrennanConroy merged commit c92eaa2 into release/5.0 Aug 18, 2020
@BrennanConroy BrennanConroy deleted the brecon/inline branch August 18, 2020 05:00
@BrennanConroy BrennanConroy added the tell-mode Indicates a PR which is being merged during tell-mode label Aug 18, 2020
@adamsitnik
Copy link
Member

It's great that this feature made it to 5.0! 👍

@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Jun 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-approved API was approved in API review, it can be implemented area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions feature-kestrel tell-mode Indicates a PR which is being merged during tell-mode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support inline application scheduling mode
6 participants