[httperf] Httperf client timeout while making progress

Mark Nottingham mnot at yahoo-inc.com
Sun Nov 26 10:00:25 PST 2006


Hm. It might be good to have a separate timeout for the whole thing,  
then (i.e., one that mirrors httperf's current behaviour). It's  
useful to use the timeout as a ceiling for when the server starts to  
get overloaded, mimicking the behaviour of an impatient user -- and  
assuring that client-side resource consumption stays reasonable. I  
suspect that with the patch below, it'll be easier to run out of fds  
or ports once the server starts to slow down...


On 2006/11/24, at 11:14 AM, 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/

--
Mark Nottingham
mnot at yahoo-inc.com





More information about the httperf mailing list