How to deal with HTTP pipelining?

[Graham Miller]

I have a server that uses http.ListenAndServe() to handle http requests.
Recently we went through the exercise of adding fine(r) grained
synchronization to our back-end query engine to allow it to handle multiple
simultaneous requests. We then removed the global lock on our query
engine, and to our surprise, requests were still handled sequentially.

I think we have traced the problem to the fact that the browser (Chrome) is
pipelining multiple requests over the same TCP connection. Then what
appears to happen is that the HTTP package waits for the completion of the
first request's handler before it reads the next request off of the socket.

So my first question, is: does this sound right, can anyone confirm?

Secondly, assuming that this is the case, is there any way to work around
this behavior, and process the two requests in parallel? Or alternatively,
to force Chrome into sending requests over separate TCP connections?

Thanks.

graham

[Brad Fitzpatrick]

Are you sure Chrome is doing HTTP pipelining? I really doubt it. HTTP
pipelining has never worked "in the wild", so no major browser has enabled
it by default. This was one of the major motivations for SPDY.

Post by Graham Miller
I have a server that uses http.ListenAndServe() to handle http requests.
Recently we went through the exercise of adding fine(r) grained
synchronization to our back-end query engine to allow it to handle multiple
simultaneous requests. We then removed the global lock on our query
engine, and to our surprise, requests were still handled sequentially.
I think we have traced the problem to the fact that the browser (Chrome)
is pipelining multiple requests over the same TCP connection. Then what
appears to happen is that the HTTP package waits for the completion of the
first request's handler before it reads the next request off of the socket.
So my first question, is: does this sound right, can anyone confirm?
Secondly, assuming that this is the case, is there any way to work around
this behavior, and process the two requests in parallel? Or alternatively,
to force Chrome into sending requests over separate TCP connections?
Thanks.
graham
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.

[Graham Miller]

Nope, not sure. However, I do know that when I run two requests
simultaneously in two different browsers (Chrome and Firefox), or on two
different machines, things work fine and execute in parallel.

I've also done a bit of printf work to make sure that the handlers were
being invoked when I expected, and they do get called seuqentially in the
single-Chrome case.

graham

Post by Brad Fitzpatrick
Are you sure Chrome is doing HTTP pipelining? I really doubt it. HTTP
pipelining has never worked "in the wild", so no major browser has enabled
it by default. This was one of the major motivations for SPDY.

Post by Graham Miller
I have a server that uses http.ListenAndServe() to handle http requests.
Recently we went through the exercise of adding fine(r) grained
synchronization to our back-end query engine to allow it to handle multiple
simultaneous requests. We then removed the global lock on our query
engine, and to our surprise, requests were still handled sequentially.
I think we have traced the problem to the fact that the browser (Chrome)
is pipelining multiple requests over the same TCP connection. Then what
appears to happen is that the HTTP package waits for the completion of the
first request's handler before it reads the next request off of the socket.
So my first question, is: does this sound right, can anyone confirm?
Secondly, assuming that this is the case, is there any way to work around
this behavior, and process the two requests in parallel? Or alternatively,
to force Chrome into sending requests over separate TCP connections?
Thanks.
graham
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.

[Graham Miller]

I guess what you're saying is that if Chrome is not pipelining that it
could still be sending two requests over the same TCP connection, which
would exhibit the described behavior.

graham

Post by Graham Miller
Nope, not sure. However, I do know that when I run two requests
simultaneously in two different browsers (Chrome and Firefox), or on two
different machines, things work fine and execute in parallel.
I've also done a bit of printf work to make sure that the handlers were
being invoked when I expected, and they do get called seuqentially in the
single-Chrome case.
graham

Post by Brad Fitzpatrick
Are you sure Chrome is doing HTTP pipelining? I really doubt it. HTTP
pipelining has never worked "in the wild", so no major browser has enabled
it by default. This was one of the major motivations for SPDY.

Post by Graham Miller
I have a server that uses http.ListenAndServe() to handle http
requests. Recently we went through the exercise of adding fine(r) grained
synchronization to our back-end query engine to allow it to handle multiple
simultaneous requests. We then removed the global lock on our query
engine, and to our surprise, requests were still handled sequentially.
I think we have traced the problem to the fact that the browser (Chrome)
is pipelining multiple requests over the same TCP connection. Then what
appears to happen is that the HTTP package waits for the completion of the
first request's handler before it reads the next request off of the socket.
So my first question, is: does this sound right, can anyone confirm?
Secondly, assuming that this is the case, is there any way to work
around this behavior, and process the two requests in parallel? Or
alternatively, to force Chrome into sending requests over separate TCP
connections?
Thanks.
graham
--
You received this message because you are subscribed to the Google
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.