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] [Updated] (HTTPCORE-424) A means to keep connections alive, even if fewer connections would suffice
Date Sat, 10 Dec 2016 10:44:58 GMT

     [ https://issues.apache.org/jira/browse/HTTPCORE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kalnichevski updated HTTPCORE-424:
---------------------------------------
         Assignee: Oleg Kalnichevski
    Fix Version/s:     (was: 5.0)
                   5.0-alpha2

> A means to keep connections alive, even if fewer connections would suffice
> --------------------------------------------------------------------------
>
>                 Key: HTTPCORE-424
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-424
>             Project: HttpComponents HttpCore
>          Issue Type: New Feature
>          Components: HttpCore NIO
>            Reporter: Tom Fitzhenry
>            Assignee: Oleg Kalnichevski
>            Priority: Minor
>             Fix For: 5.0-alpha2
>
>
> h3. Usecase
> I make 500req/s to the same server, whose response times average 5ms. This only needs
3 connections. This 500req/s occasionally bursts to 1000req/s, but as I only have 3 connections
in my connection pool, I then have to establish a bunch of connections (let's say 17), at
which point the latency suffers the cost of a TCP/SSL handshake.
> The rate then drops to the baseline 500req/s, but next time the 1000req/s burst occurs,
I'll be ready right?! I have 20 connections in my pool, waiting for me to need them.
> No, I won't be ready. By the time the burst occurs, these extra connections have timed
out, because they've not been used, and these connections are subject to TCP and HTTP time
outs (both beyond my control).
> It would be nice to have a way to keep these connections active, so they don't idle out,
ready for when I next see a burst of 1000req/s.
> h3. A possible implementation:
> A simple implementation would be to lease connections on a FIFO basis, rather than a
LIFO basis (Apache HttpAsyncClient's current behaviour). With a FIFO policy, all connections
would be kept active, so they would never idle out.
> Apache HttpAsyncClient uses a LinkedList, in LIFO mode: lines 83 and 129 of https://github.com/apache/httpcore/blob/4.4.x/httpcore-nio/src/main/java/org/apache/http/nio/pool/RouteSpecificPool.java#L83
> h3. Other HTTP clients:
> RxJava uses a Queue (FIFO): https://github.com/ReactiveX/RxJava/blob/2a8d6c75205b13cd9bef2b7f7d47723e1c86454e/src/main/java/rx/internal/util/ObjectPool.java#L28
> Vert.x uses a Queue (FIFO): https://github.com/eclipse/vert.x/blob/dbdcb3c785e9d8ff70dcce6a2e148cd3da6d15f6/src/main/java/io/vertx/core/http/impl/Http1xPool.java#L48
> async-http-client allows user to specify LIFO or FIFO: https://github.com/AsyncHttpClient/async-http-client/issues/1184



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message