[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceBatch and pipelining

On 6/28/05, Tim Bray <Tim.Bray@xxxxxxx> wrote: 
> I'm saying this:  If I wanted to post 10,000 new entries I could sit
> down and write the code right now this minute to pump them out into
> an <batch> element and send them off with a POST and parse the
> results, and I have a high confidence that it would work.  Without
> <batch>, I'd have to go and learn how to do the HTTP magic and then
> I'd have to experiment to figure if it provoked any performance
> anomalies with the Web server I wanted to use.  BTW, the world has an
> excellent understanding of the performance characteristics of pushing
> a great long stream of data into an HTTP server and having it
> dispatch the stream to code to pick it apart.

An interesting example. But what if you didn't even do pipelining and just
spawned 20 threads that each pulled from that pool of 10,000 entries
and POSTed them using the APP as it exists today? First, you would get
better resource utilization on the client, because you aren't serializing
the operations (Format all the operations into a single request, 
POST, Wait for result) instead you are getting a mix of operations
going at the same time, formatting, sending, waiting. Having a pool of 
20 or so threads operating in that manner has been shown to be a much 
better use of resources[1].  Second, by making individual requests you
would enable the server to dispatch the incoming requests as it sees
fit, for example,
the server hanlding your POST request could just be a reverse proxy that 
dispatched the requests to a multitude of
other servers. Doing this for your batch method would
require writing a custom proxy that understood your batch APP requests and 
manually breaks them up to be distributed. Does this sound vaguely 
like a SOAP problem?

I would like to see this kind of testing done if any benchmarking is
going to take place between a batched and non-batched version
of the APP.

[1] "A Design Framework for Highly Concurrent Systems"
http://www.eecs.harvard.edu/~mdw/papers/events.pdf

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org