http pipelining limits? - TCP-IP

This is a discussion on http pipelining limits? - TCP-IP ; I'd like to be able to send up to 64 http requests to a single script on a server (each request would have a different parameter) without reading the responses. I can combine several http requests into one with http/1.1 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: http pipelining limits?

  1. http pipelining limits?

    I'd like to be able to send up to 64 http requests to a single script
    on a server (each request would have a different parameter) without
    reading the responses. I can combine several http requests into one
    with http/1.1 pipelining, but is there a limit? If 64 http requests in
    a single pipelined request is to many, what would be a good amount?


  2. Re: http pipelining limits?

    yawnmoth wrote:

    > I'd like to be able to send up to 64 http requests to a single script
    > on a server (each request would have a different parameter) without
    > reading the responses. I can combine several http requests into one
    > with http/1.1 pipelining, but is there a limit? If 64 http requests in
    > a single pipelined request is to many, what would be a good amount?


    How much is too much is one of those wet piece of strings questions, but
    if the responses are large enough that they fill up your socket receive
    buffer before you read them, depending on how the server is implemented
    you may stall it by not reading the responses as expected by the
    protocol, or cause the server to think that your end has disappeared.

  3. Re: http pipelining limits?

    EJP wrote:
    > yawnmoth wrote:


    >> I'd like to be able to send up to 64 http requests to a single
    >> script on a server (each request would have a different parameter)
    >> without reading the responses. I can combine several http requests
    >> into one with http/1.1 pipelining, but is there a limit? If 64
    >> http requests in a single pipelined request is to many, what would
    >> be a good amount?


    > How much is too much is one of those wet piece of strings questions,
    > but if the responses are large enough that they fill up your socket
    > receive buffer before you read them, depending on how the server is
    > implemented you may stall it by not reading the responses as
    > expected by the protocol, or cause the server to think that your end
    > has disappeared.


    So long as you can be assured that all 64 requests will fit into the
    client's SO_SNDBUF then while you may cause a pause at the server when
    the responses fill the window and then his SO_SNDBUF at least things
    will not deadlock - the client will get all 64 requests into the
    socket and then presumeably start draining the responses.

    I would think though that the chances of the server deciding to close
    the connection before serving all 64 requests might be rather high, so
    the client will need to be careful to pay attention to that.

    Depending on the timing of the sending of the requests, and how the
    server decides to close the socket "early" (ie close() rather than
    shutdown(SHUT_WR)) the client might even have a connection reset by
    peer reported to it along the way rather than the nice clean read
    return of zero()..

    Also, to avoid disableing the Nagle algorithm it would be best if the
    client application could present all 64 requests to the transport at
    the same time via say writev() or sendmsg(). However, I am guessing
    that the server's responses will be able to clock-out the 64th request
    without too much trouble.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread