On Thu, Oct 05, 2006 at 11:23:33AM -0700, Stephen Ciscola wrote:
> I need the most blazing fast http get possible, for a
> multi-threaded app running on multiprocessor
> machine...basically it's proxying to an internal
> appliance.
>
> Responses are typically only about 8k. Except for
> body, content-type and status, everything else in
> response is pretty much a don't care.
>
> The appliance that doesn't support any kind of
> persistent connections and closes the connection after
> each response.
>
> My question is, do any of the lib curl api calls take
> advantage of any multi-threading during a simple get,
> to speed things up? Or is that too linear a process,
> and there's really no multi-threading it can do, one
> thing has to happen after the other.

HTTP in its most basic form is a simple request-response protocol, so there's
nothing you can do to optimize waiting for the response after sending the
request. You app can certainly create several threads and do several
requests simultaneously to speed up the overall transfer rate, or use
libcurl's multi interface to do simultaneous transfers from a single
thread.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved