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

Jump to bottom

net: Allow setting socket options with DialTCP #34743

Closed
dorianperkins opened this issue Oct 7, 2019 · 3 comments
Closed

net: Allow setting socket options with DialTCP #34743

dorianperkins opened this issue Oct 7, 2019 · 3 comments
Labels
FeatureRequest FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@dorianperkins
Copy link

Previous scale testing has shown that net.Dial is more expensive than net.DialTCP (#18601
) since it performs actions such as re-resolving the address on each execution. Since we're making many connections to the same IP:port, we currently avoid these performance penalties by using net.DialTCP which allows us to pass in a pre-resolved *net.TCPAddr.

For performance reasons, we also need to set socket options within this same codepath.
As of Go 1.11, net.Dialer exposes a Control function (#9661) which allows setting socket options, but this requires using the more expensive net.Dial path.

Today, it looks like we only have 2 options:

  1. set socket options but sacrifice performance by using net.Dial, or
  2. we continue to use net.DialTCP but cannot set socket options.

Is the Go team open to exposing some way to use net.DialTCP which allows setting socket options? We're happy to contribute code if needed.
@katiehockman katiehockman added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 10, 2019
@katiehockman
Copy link
Contributor

Seems related to #18601

/cc @bradfitz

@bradfitz
Copy link
Contributor

What performance numbers do you see between the two?

Can you summarize where you're seeing the performance loss between Dial and DialTCP? #18601 looks like it's kinda long and about an old Go version and talking about things that are common to both Dial and DialTCP.

If the main cost is resolving the ip:port from the name, can't you do that first, and then just call Dial with the string-ified IP:port? That'll at least skip DNS.

Before we add new API (e.g. Dialer.DialTCP), we'd really want to understand the problem first.

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 10, 2019
@gopherbot
Copy link

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Nov 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bradfitz @dorianperkins @gopherbot @katiehockman