Daniel Stenberg wrote:
> On Thu, 25 Aug 2005, Martin Vogt wrote:
>
>> 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)
>
> 1000 requests in 19 second is extremly slow indeed. Doesn't a network
> trace (or similar) reveal any details? Are the interval times roughly
> equal between all requests?
>
Here ist the output from the program:
vogt@media2[dbaccess]>./curltest -u http://media2.cluster/a.jpg
next iteration:936
response:200
removed:1
response:200
[.....goes on]
response:200
removed:195
timeout!
timeout!
response:200
removed:196
response:200
removed:197
[...fine...]
removed:387
response:200
removed:388
timeout!
timeout!
response:200
removed:389
response:200
response:200
[...still running..]
removed:547
response:200
removed:548
timeout!
timeout!
timeout!
response:200
removed:549
response:200
removed:550
moved:390
[running]
removed:740
response:200
removed:741
timeout!
timeout!
timeout!
timeout!
timeout!
timeout!
timeout!
response:200
removed:742
response:200
removed:743
running until end, no more timeouts.

>When looking int the strace I have many (1500 entries) like:
>rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
>gettimeofday({1124990771, 399867}, NULL) = 0

>From the ab.c source there is a comment like:
#ifdef SIGPIPE
    apr_signal(SIGPIPE, SIG_IGN); /* Ignore writes to connections that
                                         * have been closed at the other
end. */
#endif

Maybe this needs some investigation.

These are the EINPROGRESS errors:

>socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 32
>fcntl64(32, F_GETFL) = 0x2 (flags O_RDWR)
>fcntl64(32, F_SETFL, O_RDWR|O_NONBLOCK) = 0
>connect(32, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("192.168.
>9.2")}, 16) = -1 EINPROGRESS (Operation now in progress)
>poll([{fd=32, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1

I will give a better report tomorrow.

Im currently writing the same test in apr. Maybe this gives some idea
what could be the problem.

Thanks & regards,

Martin
Received on 2005-08-25