[
https://issues.apache.org/jira/browse/THRIFT-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012862#comment-15012862
]
Adam Beberg commented on THRIFT-3429:
-------------------------------------
Ah, I misunderstood you as talking about the entire connection through to the
server, however... why would you need thousands of clients in one transport? If
you're load testing, you will want the load generator to have many goroutines
each with it's own Thrift client (not shared) - that way you will have many
connections to the server side creating load. You reuse the same keep-alive
connection over and over in the one goroutine.
Say 1000 goroutines per load generator, creating 1000 Thrift clients sending
messages, talking to the server. Running 10 of them gives you 10,000 TLS
connections on the server.
> 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)
