[
https://issues.apache.org/jira/browse/HTTPCORE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162349#comment-17162349
]
Carter Kozak commented on HTTPCORE-639:
---------------------------------------
Hi Michael,
I've seen HTTPCLIENT-2093, but I didn't see a discussion on the mailing list,
so I may be missing some historical context.
> A question before we start, why are your servers suboptimal by consuming the
> entire body, but still rejecting based on headers?
They tend to be well defined with generally small request bodies for RPC style
traffic. Using http/1.1 we've observed better performance draining request
bytes and allowing connections to be reused as opposed to leaving the
connection in a state that cannot be reused. Large uploads use expect
100-continue to validate headers without a transfer cost. This definitely isn't
something that I would suggest as a sane default in a general purpose library,
but in a well controlled environment improves our throughput by an order of
magnitude.
> Why does your interface not contain two methods? For the chunk size and the
> timeout? How would an implementation for you look like when request and
> socket are necessary? Aren't two config options enough?
Two configuration options may be sufficient, my example was an initial
brainstorm.
I chose to include the socket so that I could differentiate between ssl and
plain http connections because the performance issue only impacts SSLSocket. My
implementation might as well be as safe as possible when the performance cost
is minimal.
I have an implementation in mind where the HttpEntity is taken into account,
the full request isn't necessary though. I would check if the HttpEntity is
repeatable and the content-type to narrow the scope of avoiding the
out-of-order check, but those aren't a requirement for me. What do you think?
I don't think we would ever need to modify the timeout, if I understand
correctly, one millisecond is used because we expect to get a timeout after a
millisecond, and failure to time out means a response has been sent. I don't
think there's any reason to provide a higher value, and zero would result in
the request hanging until the server closes the connection. I suppose we could
provide a separate timeout which is applied to individual writes which could be
much lower than the socket timeout used to wait for a response, that way if a
deadlock scenario was created the client would time out relatively quickly.
Such a feature could be useful, but wouldn't necessarily have any overlap with
the ResponseOutOfOrderStrategy.
> Consider a configurable ResponseOutOfOrder strategy for
> DefaultBHttpClientConnection
> ------------------------------------------------------------------------------------
>
> Key: HTTPCORE-639
> URL: https://issues.apache.org/jira/browse/HTTPCORE-639
> Project: HttpComponents HttpCore
> Issue Type: New Feature
> Components: HttpCore
> Reporter: Carter Kozak
> Priority: Major
>
> In a known environment where the server fully reads full request bodies
> before sending a response, I would like to disable the expensive
> checkForEarlyResponse checks implemented by
> DefaultBHttpClientConnection.sendRequestEntity.
> Using TLS the check blocks for 1ms every 8kb, which limits the upload rate to
> at most eight megabytes per second, relatively low in a data-center
> environment.
> Proposed interface:
> {code:java}
> public interface ResponseOutOfOrderStrategy {
> /**
> * Returns the interval in bytes describing how often the socket is
> checked for an out-of-order response.
> * The default implementation uses 8kb. A value of zero results in checks
> being disabled, this may result
> * in requests blocking until the socket timeout is reached while a
> server sends an out-of-order response.
> */
> int determineResponseCheckIntervalBytes(ClassicHttpRequest request,
> Socket socket);
> }
> {code}
> I'd be happy to implement and contribute such a feature if you agree that
> it's reasonable.
> I appreciate any input and feedback you can provide!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
