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

Open
dorianperkins opened this issue Oct 7, 2019 · 2 comments

Comments

@dorianperkins
Copy link

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
Contributor

commented Oct 10, 2019

Seems related to #18601

/cc @bradfitz

@bradfitz

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.