Re: performance question
Date: Thu, 31 Jan 2002 08:05:26 +0100 (MET)
On Wed, 30 Jan 2002, rick vaillancourt wrote:
> A multi threaded C++ service makes a call to a known URL (this doesn't
> change), the URL string has a couple of replacement parameters for a lookup
> (so this changes per execution).
> I plan on having a cache of preinit'd CURL*'s to choose from, where I mutex
> around grabbing and dropping the handle (passing back one that is not in
> use). I then would re-set the curl options before every execution like the
> documentation suggests(I may have to add some header info for security and
> run https - but I am not yet doing that):
> > > curl_easy_setopt(curl, CURLOPT_URL, buffy );
> > > curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writeMemoryCallback);
> > > curl_easy_setopt(curl, CURLOPT_FILE, (void *)&chunk);
> Does anyone have any advice on squeezing the most performance out of this?
> Additional options to set?
Using the same handle as much as possible should be fastest. libcurl should
be able to keep the connection alive praticly forever (since you keep using
the same host), saving you from at least re-connects, slow-start TCP and
repeated name resolves.
> Is there any advantage to setting curl_easy_setopt for CURLOPT_PROXY (would
> this conflict with the url that has it as part of the string already?)
No, I can't see why using a proxy whould be better. Unless the proxy has a
cache that it'll use that'll deliver the URLs faster than the actual remote
server will when used without proxy. Proxies also usually keep connections
alive slightly longer than "normal" servers, why that may have importance too
if you have idle time between your connects that are longer than the server's
persistant time but shorter than the proxy's.
> or set CURLOPT_MAXCONNECTS=1(less to look at per CURL*?) in this scenario?
The connection cache is size 5 by default, and as you only use one host all
the time, it'll find the host just as fast with 100 as with 1 (the internals
is using a plain array for this data).
Also, finding an existing connection should be much faster than name
resolving and connecting to the host is.
To get more detailed information, we would need to profile the code and see
where it spends the most time. That would of course be very interesting and
useful, but I personally don't have the time for that at the moment.
-- Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/Received on 2002-01-31