[httperf] Httperf client timeout while making progress

Ted Bullock tbullock at canada.com
Fri Nov 24 17:18:22 PST 2006


Hi Martin,

Are you interested in having either of the patches below added to our work?

Let me know,

Thanks !

-Ted Bullock


Martin Arlitt wrote:
> hi Chris
> 
> you are correct, there is a discrepancy between the behaviour and the
> documentation.  more specifically, httperf does not appear to update the
> timeout value for the fourth case, so in effect it will time out X seconds
> after it starts waiting for the start of the reply, rather than from when
> the start of the reply is received.
> 
> a fix that resets the timer each time a new packet in the reply is
> received is:
> 
> diff -urN httperf-0.8/core.c httperf-0.8-fix2/core.c
> --- httperf-0.8/core.c  2000-10-31 18:57:50.000000000 -0500
> +++ httperf-0.8-fix2/core.c     2006-11-24 12:08:33.000000000 -0500
> @@ -591,7 +591,12 @@
>    while (buf_len > 0);
> 
>    if (s->recvq)
> -    set_active (c->conn, &rdfds);
> +    {
> +      s->recvq->timeout = param.timeout + param.think_timeout;
> +      if(s->recvq->timeout > 0.0)
> +       s->recvq->timeout += timer_now ();
> +      set_active (c->conn, &rdfds);
> +    }
>  }
> 
> a fix that sets the appropriate start time, but does not update for each
> packet is
> 
> --- httperf-0.8/core.c  2000-10-31 18:57:50.000000000 -0500
> +++ httperf-0.8-fix/core.c      2006-11-24 11:38:04.000000000 -0500
> @@ -578,6 +578,12 @@
>      {
>        c = s->recvq;
>        assert (c);
> +      if(s->state == S_REPLY_STATUS)
> +       {
> +         c->timeout = param.timeout + param.think_timeout;
> +         if (c->timeout > 0.0)
> +           c->timeout += timer_now ();
> +       }
>        http_process_reply_bytes (c, &cp, &buf_len);
>        if (s->state == S_REPLY_DONE)
>         {
> 
> 
> I think you want the first one.
> 
> please let me know if this works for you.
> 
> thanks
> 
> Martin
> 
>  On Fri, 24 Nov 2006, Chris Wilson wrote:
> 
>> Hi all,
>>
>> First of all, thanks for writing httperf! It looks like an excellent tool
>> and most suitable for the kind of network performance tests and debugging
>> that I'm currently doing (fixing university networks in Kenya).
>>
>> However, I think I've discovered a discrepancy between httperf's behaviour
>> and the documentation. The man page says of the option --timeout:
>>
>>     Specifies the amount of time X that httperf is willing to wait
>>     for a server reaction. [...] This timeout value is used when
>>     establishing a TCP connection, when sending a request, when waiting for
>>     a reply, and when receiving a reply. If during any of those activities
>>     a request fails to make forward progress within the alloted time,
>>     httperf considers the request to have died, closes the associated
>>     connection or session and increases the client-timo error count.
>>
>> Now that makes perfect sense to me, and mirrors the way that I think a
>> browser would work. My definition of "making forward progress while
>> receiving a reply" is that packets continue to be received. So as long as
>> the delay between packets (or TCP data delivery) does not exceed the
>> timeout, httperf will not give up on the connection.
>>
>> However, I think that I have observed httperf behaving differently.
>> Specifically, it seems to apply the --timeout to receiving the entire
>> response. Therefore, if I specify a reasonable timeout of 30 seconds, and
>> download a large page over a slow connection, httperf reports a timeout
>> error, even though a browser would not.
>>
>> I've attached a pcap file and httperf debug log (level 3) as an example.
>>
>> If there is any choice over this behaviour, I would like to configure
>> httperf to behave the way that I described above, i.e. not to time out the
>> connection as long as it continues to receive packets.
>>
>> Thanks in advance for your help!
>>
>> Cheers, Chris.
>> --
>> (aidworld) chris wilson | chief engineer (http://www.aidworld.org)
> _______________________________________________
> httperf mailing list
> httperf at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/httperf/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
Url : http://napali.hpl.hp.com/pipermail/httperf/attachments/20061124/1a960789/smime.bin


More information about the httperf mailing list