[ 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