cURL / Mailing Lists / curl-library / Single Mail


Re: curl_global_init performance

From: Tim Ruehsen <>
Date: Fri, 30 Aug 2013 15:48:42 +0200

On Friday 30 August 2013 13:20:10 Daniel Stenberg wrote:
> On Fri, 30 Aug 2013, Tim Ruehsen wrote:
> >> Exactly how long time are we actually talking about here, the specific
> >> SSL_load_error_strings() call I mean?
> >
> > Wow, that's a "manager" question ;-)
> Hey, I am _managing_ this project!

Yes, but you are not "managing" the project (that would nearly be an insult,
but that is not my intention and that's why there is the smiley above).
Sorry for not being clear, i tried to express my puzzling about your question,
since I was talking about CPU impact, never about absolute times (these
heavily depend on network speed in this context).

But to answer your question, on my (pretty fast) machine where I am working
right now (having a fast network connection to my server):
typical time wget -q -o index.html http://myserver/index.html:
real 0m0.003s
user 0m0.000s
sys 0m0.000s

typical time curl -s -o index.html http://myserver/index.html:
real 0m0.012s
user 0m0.004s
sys 0m0.000s

The 'time' command is not very exact, it gives just a direction.
I agree, that in normal situations (user starting curl to download one file),
a difference of a few milliseconds do not matter at all.
But what about scripts, that download small files in a loop in a fast
network... e.g. using wget takes 10s while curl would take 50s ?

An example, where I need several hundred simultaneous web clients:

I (resp. my company) sell and maintain telephony application servers with
pretty much parallel lines (up to 960 lines in parallel) . Due to hardware
restrictions and costs, many customers stay with older hardware with not very
much CPU power (different 1 Core Intel CPU). One of them is a TV Broadcaster
with selling / gaming shows. The applications are controlled by a web server
that is being polled every few seconds by each application instance (every
caller has it's own process instance). I know this is a bad design, but the
customer wanted it exactly that way and I couldn't convince them otherwise.
They had their own (web) developers...
On a "TV Hit" (as we call it) all the lines might get a caller within seconds.
This means a few hundred calls to curl or wget at once...
The system is near-realtime, means the callers could experience stuttering
when CPU impact is too high.
At least I had to throw out popen("curl...") and replace it by libcurl. That
was enough in that time to reduce CPU impact and since than the number of
callers slowly drop...

What about (very) slow embedded systems ?
Could CPU impact matter here ?
I admit, I am not an expert in this.

> We also support about 9 other SSL backends, so you could
> easily avoid this particular problem by switching to another without
> needing any code changes.

In all cases I use the Linux distributions packages, these use either OpenSSL
or GnuTLS.

> If you want something to change in libcurl, I need it motivated. I want to
> be convinced it is worthwhile to spend energy on.

I can't attach a beer, but hopefully this motivates you :-)

But seriously, there are corner cases where the difference matters.
And of course, it is a matter of being sporty :-)

Regards, Tim

List admin:
Received on 2013-08-30