hc-dev mailing list archives

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

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

Andrew Shore commented on HTTPCLIENT-1809:
------------------------------------------

Thanks for the info Oleg. With a single HttpClient instance, we were able to get up to higher
TPS with a connection pool size of 200 and average number of threads about 75. Anything past
that performance degraded pretty quickly. 

Does HttpClient have performance reports we could compare our results to?



> 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
proceeding. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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


Mime
View raw message