>-- Messaggio originale --
>From: Daniel Stenberg <daniel_at_haxx.se>
>To: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
>Subject: Re: CURLINFO_REDIRECT_TIME is really fixed?
>Reply-To: curl-library_at_lists.sourceforge.net
>Date: Mon, 21 Oct 2002 15:41:13 +0200 (MET DST)
>
>
>On Mon, 21 Oct 2002 xx_serena_xx_at_virgilio.it wrote:
>
>> the values returned by curl_easy_getinfo(..,CURLINFO_REDIRECT_TIME,..)
>have
>> someting wrong.
>
>> As example, here are some values (times in second) i've obtained in 4
different
>> executions of my test:
>> |#test:
>> option used | 1 2 3 4
>> ____________________________|_____________________________________
>> CURLINFO_NAMELOOKUP_TIME | 0.01 0.01 0.01 0.01
>> CURLINFO_CONNECT_TIME | 0.01 0.01 0.01 0.01
>> CURLINFO_STARTTRANSFER_TIME | 0.052 0.072 0.02 0.058
>> CURLINFO_REDIRECT_TIME | 1.007 1.006 1.002 1.006
>> CURLINFO_TOTAL_TIME | 1.175 1.217 1.371 1.368
>>
>> As you can see, the REDIRECT_TIME introduces 1 second (this appened for
>> every execution done).
>
>I don't agree with you. Look at the names of those timers you've read.
Look
>at the timer you got just before the REDIRECT time: STARTTRANSFER_TIME.
At
>what point do you think that time stamp is set? I'd say that is before
any
>transfer.
>
>The REDIRECT_TIME is set after having read enough amount of data (all
>headers). I can't but to believe that reading the headers takes about 1
>second in your test cases.
>
>The timers can never add time to other timers, they're all just time stamps
>recorded at various stages in the process.
>
>> Measuring the same times with a tool manually developed for taking
>> intermediate times, i've confirmed that this values are wrong.
>
>How much wrong? How do you time this to tell?
>

The total time i've registered with my tool is about 0.150 sec for all tests
instead of CURLINFO_TOTAL_TIME that's over 1 second.
That's because i've used one client that submits requests to a server on
the same LAN (100Mbit/sec); this server redirects the requests to another
server on the same LAN; the second server responds to the client with the
requested page.
This means that there is only one redirection.
So the scene is like this:
Tlookup (for server1)
Tconnect (for server1)
Tresponse for the redirection header (from server1)
Tlookup (for server2)
Tconnect (for server2)
Tresponse for the requested page (from server2)

Consider that the 2 servers are on the same LAN of the client and the
requested document is a 1MB size (so there's a transfer time about 100ms).
To give you an idea of the times i've measured here are 5 rows corresponding
to 5 iterations of my tool:
in the first column there are the times of the transactions with the first
server and in the second column those of the transactions with the second
server (total time is the sum of the 2 times)

0.003 0.143
0.002 0.139
0.002 0.139
0.002 0.154
0.002 0.135

As you can see the total time is <= 200ms.
There's no reason for a time >= 1sec (registered with CURLINFO_TOTAL_TIME
in cases with redirection) when the testing platform is like mine.

>> I've not time to find the reasons of this added second in the source
code,
>> but i've thought it was right to send this message to you.
>
>Sure, it's never wrong to mail us about suspected problems.
>
>> Make me know if there's some error by my side of it's not true the
>> CURLINFO_REDIRECT_TIME in lubcurl 7.9.8 was fixed.
>
>It was fixed. Just go try an older version and you'll get a very different
>time.
>
>I never ever guarantee anyone that there are no bugs remaining. There may
>very well be a bug lurking in this area still. With your help we might
be
>able to track it down and fix this.
>
>--
> Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>

-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote
Received on 2002-10-22