Keeping HTTP connection alive even if there are no more requests

[AntZ]

I use Node.js as HTTPS client, not a server. I need to issue some 10
HTTPS requests a second to a remote server. It works, but every HTTPS
request is in separate HTTPS connection.

The problem is in agent logic:
} else {
// If there are no pending requests just destroy the
// socket and it will get removed from the pool. This
// gets us out of timeout issues and allows us to
// default to Connection:keep-alive.
socket.destroy();
}

There are two choices:
1) There are more HTTPS requests to the location, keep connection live
2) No more HTTPS requests to the location, just close the connection

I desperatly need third variant - I want to keep connection alive as
there will be next request in no longer than 100ms.

For now the only solution I see is to replace a standard Agent with my
own one. Are there more simple solutions? Is there an easy way to make
keepalive client connections disconnecting on timeout?

HTTPS connection handshake is expensive

[Jann Horn]

Have a look at https://github.com/mikeal/request/blob/master/forever.js
- "request" can do forever requests (although I didn't know that isaacs
has added HTTPS support :) ).

Try something like this:

var request = require('request').forever();
// use request according to the documentation now

[Jimb Esser]

We ran into this same thing, and I ended up just writing a small patch
to the HTTPS agent to hold on to https sockets for 10 seconds after a
request finished. This ended up roughly tripling our SimpleDB
performance (back to Node 0.4 performance levels, which did connection
pooling by default, or at least had an option for it).

Here's a gist with some code you can run on your HTTPS agent to add
pooling, if forever doesn't work for you (I've never looked into it
myself). https://gist.github.com/2346805 Warning: quite hacky, and
asserts that the underlying node implementation is exactly what it
expects (tested on v0.6.12) - an actual node patch would probably be
better, but this works for now.

On Apr 7, 3:44 pm, Jann Horn <jannh...@googlemail.com> wrote:
> Am Donnerstag, den 05.04.2012, 23:19 -0700 schrieb AntZ:
>
>
>
>
>
>
>
>
>
> > I use Node.js as HTTPS client, not a server. I need to issue some 10
> > HTTPS requests a second to a remote server. It works, but every HTTPS
> > request is in separate HTTPS connection.
>
> > The problem is in agent logic:
> >     } else {
> >       // If there are no pending requests just destroy the
> >       // socket and it will get removed from the pool. This
> >       // gets us out of timeout issues and allows us to
> >       // default to Connection:keep-alive.
> >       socket.destroy();
> >     }
>
> > There are two choices:
> > 1) There are more HTTPS requests to the location, keep connection live
> > 2) No more HTTPS requests to the location, just close the connection
>
> > I desperatly need third variant - I want to keep connection alive as
> > there will be next request in no longer than 100ms.
>
> > For now the only solution I see is to replace a standard Agent with my
> > own one. Are there more simple solutions? Is there an easy way to make
> > keepalive client connections disconnecting on timeout?
>
> > HTTPS connection handshake is expensive
>

> Have a look athttps://github.com/mikeal/request/blob/master/forever.js

> - "request" can do forever requests (although I didn't know that isaacs
> has added HTTPS support :) ).
>
> Try something like this:
>
>     var request = require('request').forever();
>     // use request according to the documentation now
>

>  signature.asc
> < 1KViewDownload

[Jann Horn]

On Mon, Apr 09, 2012 at 03:00:56PM -0700, Jimb Esser wrote:
> We ran into this same thing, and I ended up just writing a small patch
> to the HTTPS agent to hold on to https sockets for 10 seconds after a
> request finished. This ended up roughly tripling our SimpleDB
> performance (back to Node 0.4 performance levels, which did connection
> pooling by default, or at least had an option for it).
>
> Here's a gist with some code you can run on your HTTPS agent to add
> pooling, if forever doesn't work for you (I've never looked into it
> myself). https://gist.github.com/2346805 Warning: quite hacky, and
> asserts that the underlying node implementation is exactly what it
> expects (tested on v0.6.12)

Does it handle weird cases correctly? Like, you send a new request at the same time the server decides to kill the connection because it's idle? requests forever handles all that.

> - an actual node patch would probably be
> better, but this works for now.

It's never going to become a node core feature. You have to resend requests if the server kills the connection without a response just after you sent your request, for example. That's RFC compliant, I think, but it's a high-level abstraction.