[httperf] Httperf client timeout while making progress

Martin Arlitt arlitt at granite.hpl.hp.com
Mon Nov 27 06:20:12 PST 2006


hi Mark

I agree with you, that is why I included the second patch, which I think
does what you are suggesting.  please let me know if you disagree.

thanks

Martin

On Sun, 26 Nov 2006, Mark Nottingham wrote:

> 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