Does node.js support HTTP Pipelining?

[felix]

I recently read an article about Optimizing HTTP: Keep-alive and
Pipelining at http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipelining/.

I went through the latest doc and did not find information about
pipelining.

Does node.js support HTTP pipelining? Thx

-Felix

[Koichi Kobayashi]

Hi,

http.Server supports pipelining, but http.ClientRequest does not.

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[felix]

Koichi, Thx.

Just found out "Google Introduces HTTP Pipelining In Chrome 17"
http://www.conceivablytech.com/9688/products/google-introduces-http-pipelining-in-chrome-17

On Oct 21, 11:44 pm, Koichi Kobayashi <koic...@improvement.jp> wrote:
> Hi,
>
> http.Server supports pipelining, but http.ClientRequest does not.
>
>
>
>
>
>
>
> On Thu, 20 Oct 2011 17:21:33 -0700 (PDT), felix <felix0...@gmail.com> wrote:
> > I recently read an article about Optimizing HTTP: Keep-alive and

> > Pipelining athttp://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipel....

[Mikeal Rogers]

By default the HTTP client does keep-alive and pooling, which *can* be better than pipelining.

The problem with pipelining is that the responses must be sequential. So, if you're talking to CouchDB and you do one big bulk read and then 7 small reads the small reads will all have to wait for the big bulk read to finish. With keep-alive and pooling you're optimizing for concurrency and you're assuming the benefits will outweigh the extra roundtrips to setup up the extra pooled connections.

It's a tough balance but in my experience it's better to do keep-alive + pooling with HTTP because the time it takes for a response to return is usually greater than the roundtrip if you're making enough requests for this to matter. However, something like Redis is much better suited to pipelining because requests are returned almost immediately and what you mainly want to do is cut down on roundtrips.

-Mikeal

[felix]

Mikeal, Thx. Very useful! :)
Especially you gave us use cases between keep-alive and pipelining~

On Oct 23, 4:53 am, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
>  By default the HTTP client does keep-alive and pooling, which *can* be better than pipelining.
>
> The problem with pipelining is that the responses must be sequential. So, if you're talking to CouchDB and you do one big bulk read and then 7 small reads the small reads will all have to wait for the big bulk read to finish. With keep-alive and pooling you're optimizing for concurrency and you're assuming the benefits will outweigh the extra roundtrips to setup up the extra pooled connections.
>
> It's a tough balance but in my experience it's better to do keep-alive + pooling with HTTP because the time it takes for a response to return is usually greater than the roundtrip if you're making enough requests for this to matter. However, something like Redis is much better suited to pipelining because requests are returned almost immediately and what you mainly want to do is cut down on roundtrips.
>
> -Mikeal
>
> On Oct 20, 2011, at October 20, 20115:21 PM, felix wrote:
>
>
>
>
>
>
>
> > I recently read an article about Optimizing HTTP: Keep-alive and

> > Pipelining athttp://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipel....