Re: RFC: continous counters (fwd)

On Mon, Nov 05, 2007 at 01:00:13AM +0100, Krzysztof Oledzki wrote:
> If you can only have a thousands of users. When you are going to stream
> A/V content the limit of simultaneous users are not going to be high
> enough to make stats smooth, especially when an average session may last
> for >1h.

Yes, with A/V there is no workaround. That makes me think that I know someone on the list who will certainly like it ;-)

> >However, there's something which puzzles me. I think you should not update
> >the stats as long as the backend has not been assigned or the session
> >closed
> >(flags & BE_ASSIGNED I believe). The reason is that with current patch, the
> >backend will never be updated for the size of the request headers.
>
> This is somehow different from what I observed: with first call "flags &
> BE_ASSIGNED" indeed returns 0, but at the same time s->req->total is
> still 0. If I understand it right it gets incremented only after a request
> get delivered to a server.

Oh, that's possible. I'll have to check too.

> So, changing:
> if (s->fe->options & PR_O_CONTCNT)
> into:
> if ((s->fe->options & PR_O_CONTSTATS) && (s->flags & SN_BE_ASSIGNED))
> does not change anything from counter's point of view, hovewer it prevents
> this empty call so I trust you that this is better.

If what you say is true, the second check can be removed, however adding a comment above it justifying why it cannot cause trouble is important.

I have tried your patch. Oddly, it was mangled again and did not apply. But differently this time : the unchanged lines, which began with a space had their space doubled. This may be because of the encoding, I don't know. I think the most reliable solution is to attach them, even if that makes it harder for inlined comments. We'll see in the long term what is preferable.

Anyway, I fixed it using sed and tested it. The performance impact when the option is disabled is not measurable (that's good). When it is enabled, it only has a very small impact (I measured about 0.5%), which means that people who use scripts to generate configurations will be able to enable it by default without a big trade-off.

Would you please rediff it against -master, so that I apply it there ?

Thanks,
Willy Received on 2007/11/05 08:41