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

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

Comments

@dorianperkins
Copy link

@dorianperkins dorianperkins commented Oct 7, 2019

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

This comment has been minimized.

Copy link
Member

@katiehockman katiehockman commented Oct 10, 2019

Seems related to #18601

/cc @bradfitz

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Oct 10, 2019

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.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 10, 2019

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.)

@gopherbot gopherbot closed this Nov 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.