Re: Timings and HTTP keep-alives

Thanks, Willy. That makes sense.

It does seem to mean there is a slight loss of information, in that you can't distinguish idle time between requests from time the client spends sending a new request. But that's not really a big deal.

For clarity in the docs (since they are already so comprehensive), I might suggest mentioning in section on HTTP log format that Tq and Tt are cumulative for the connection (while Tw, Tc, and Tr are of course per request).

Thanks again for your responsiveness.

Josh

On Thu, Apr 8, 2010 at 2:05 PM, Willy Tarreau <w#1wt.eu> wrote:

> Hi Joshua,
>
> On Wed, Apr 07, 2010 at 04:14:51PM -0700, Joshua Levy wrote:
> > Hi,
> > I've been using the new http-server-close option for HTTP
> > keep-alives and it's been working well -- thanks for this feature.
> >
> > I may be missing something, but I did not see much detail in the
> > docs on how the various timings in the logs, particularly Tq and Tt,
> > work when keep-alives are in use. It seems these are measured
> > from the start of the connection, not the request?
>
> They're normally measured from the start of the connection for the
> first request. For next requests, they're measured from the end of
> previous response. This is what lets you see how much time a
> connection is maintained without the client sending anything on it.
>
> > Is there a
> > recommended way to get per-request timings in this situation?
>
> You have them the same way as before, the only point you should
> consider is that you don't have an easy way to know what requests
> shared what connection, you have to look at the source IP:port for
> that. As a hint, most often requests with non-zero request time
> are second an ongoing, because few clients are doing pipelining,
> so you observe at least an RTT between the end of the first
> response and the beginning of the second one.
>
> Regards,
> Willy
>
>
Received on 2010/04/09 00:06