[
https://issues.apache.org/jira/browse/THRIFT-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012753#comment-15012753
]
Justin Larrabee edited comment on THRIFT-3429 at 11/19/15 4:17 AM:
-------------------------------------------------------------------
I am sorry but you are incorrect about how connections are created and recycled
within the Go HTTP package.
When you call Go's HTTP client.Do method the client itself chooses to either a)
create a new connection for you and go through the TLS handshaking process (yes
I am familiar with this) or b) utilize an existing connection that has been
marked for keep-alive. Those keep-alive connections only exist if you are a
good citizen with them and return them to the pool (see THRIFT-3430).
So if you actually are interested in top performance for thousands of
THttpClient instances you would a) use a custom http.Client and http.Transport
with a large MaxIdleConnsPerHost setting (the default is 2 per-host) and b)
read and close HTTP response bodies as fast as possible. My suggestion
addresses b) and my fix in THRIFT-3405 addressed a).
I have developed a load testing application and I needed to do both a) and b)
with a fork of the THttpClient so I could get to a reasonable number of
concurrent connections without the overhead of the handshake you mentioned
causing the whole thing to fall flat on its face.
That said I'm not married to this suggestion as described. Perhaps there is a
simpler way to attain the same goal or it should be left strictly to the user
of the transport to call Close() if they want it returned to the pool as
quickly as possible.
was (Author: justinlarrabee):
I am sorry but you are incorrect about how connections are created and recycled
within the Go HTTP package.
When you call Go's HTTP client.Do method the client itself chooses to either a)
create a new connection for you and go through the TLS handshaking process (yes
I am familiar with this) or b) utilize an existing connection that has been
marked for keep-alive. Those keep-alive connections only exist if you are a
good citizen with them and return them to the pool (see THRIFT-3430).
So if you actually are interested in top performance for thousands of
THttpClient instances you would a) use a custom http.Client and http.Transport
with a large MaxIdleConnsPerHost setting (the default is 2 per-host) and b)
read and close HTTP response bodies as fast as possible. My suggestion
addresses b) and my fix in THRIFT-3405 addressed a).
I have developed a load testing application and I needed to do both a) and b)
with a fork of the THttpClient so I could get to a reasonable number of
concurrent connections without the overhead of the handshake you mentioned
causing the whole thing to fall flat on its face.
> Go THttpClient option to fully read/close HTTP response body after Flush
> ------------------------------------------------------------------------
>
> Key: THRIFT-3429
> URL: https://issues.apache.org/jira/browse/THRIFT-3429
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Reporter: Justin Larrabee
> Priority: Minor
>
> Currently the THttpTransport holds onto the HTTP response body until the
> owner calls Close(). When using keepalive this has the side effect of not
> releasing the TCP connection back to the HTTP client's pool until it is
> called. When creating many concurrent THttpTransport's this delay can cause a
> lot of additional connections to be created.
> I would suggest that the transport be configurable to fully read and close
> the HTTP response body after a Flush() call so that the connection is
> returned to the pool as quickly as possible.
> I would love some opinions on this suggestion. My patch for issue 3405 added
> a THttpClientOptions struct to make it easy to support additional features
> like this improvement without needing to alter the new public constructors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
