hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1809) Thread contention in PoolingHttpClientConnectionManager
Date Thu, 02 Feb 2017 19:52:52 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850379#comment-15850379

Oleg Kalnichevski commented on HTTPCLIENT-1809:

Here is the benchmark that I use to benchmark performance of HttpClient and HttpAsyncClient.
It has not been updated for a few releases but should still quite representative.



> Thread contention in PoolingHttpClientConnectionManager
> -------------------------------------------------------
>                 Key: HTTPCLIENT-1809
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1809
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5
>            Reporter: Andrew Shore
>            Priority: Minor
>              Labels: perfomance
> We (AWS SDK for Java) have been investigating reports of poor performance in the SDK
and have narrowed it down to thread contention issues in PoolingHttpClientConnectionManager.
Up to a certain TPS, performance is great and their is no issue. After a certain TPS (approx
8000 in our load tests), performance tanks hard and most threads end up stuck waiting on a
lock in AbstractConnPool (in either lease or releaseConnection).
> https://github.com/apache/httpcore/blob/4.4.x/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L403
> This quickly locks up the application as it tries to meet the incoming TPS. We have been
able to workaround this and achieve much higher throughput but having multiple SDK clients
and round robin selecting them to hand off to threads. This allowed us to easily scale up
to 16, 000 TPS. We wanted to open up a dialog with the maintainers of the Apache HTTP client
to see if this is a known issue/limitation and what options we have for getting around it.
We aren’t opposed to re-implementing the connection manager to be more performant but since
it’s a pretty sizable chunk of work we wanted to ensure that’s the best path forward before

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message