On 8/25/05, Martin Vogt <vogt_at_itwm.fraunhofer.de> wrote:
> Cory Nelson wrote:
> > libcurl (or anything else using select) probably isn't the best choice
> > for benchmarking, but i do see one major flaw:
> >
> >
>
> I didnt thought that its that slow. The apache2 bench ab2
> performs 1000 requests in 0.4 seconds, the libcurl based
> tesprogram ist 48 time slower. (19 seconds)
>
> Even if select is slow, I dont think it should be _that_ slow.

well a benchmark should do its best to keep as low cpu as possible to
keep results for the daemon as accurate as possible.

> Im just reading the ab.c source.
> They use poll and pollsets.
> I think its possible to extract the necessary code, apr is similar "high
> level" as libcurl.
> But select cant be that slow!

select() is indeed much slower than epoll or completion ports. though
it shouldn't be significantly slower than a normal poll(), so i dunno
what's going on with that.

> When using strace with the testprogramm I dont get any ideas
> what can be the problem. Many Sockets in "EINPROGRESS"
>
> > dev_null() printing stuff out will be a major drain on performance,
> > especially with that endl flushing the stream... consider having it
> > just return size*nmemb. if you must print something, make a static
> > variable and only print when (++var%500) == 0.
> >
> >
> No this is not the problem. I just commented the code.
> It still has the timeouts.
> When looking at the curl implementation of curl_multi_perform
> it looks a bit too complex, but currently I have no clue what
> makes the testprogram/libcurl slow.
> Btw: just check curl-7.14.0, same behaviour.
>
>
> Martin
>
>
>

-- 
Cory Nelson
http://www.int64.org