Re: RFC: continous counters (fwd)

On Mon, 5 Nov 2007, Willy Tarreau wrote:

> 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 ;-)

Nice. ;)

>>> 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.

Please do. I might have overlooked something.

>> 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.

Since this does not cost too much I think it may be safe to keep it. If anything changes it will not break it. What do you think?

> 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.

I am starting to hate this "pine". :( It was the last patch mailed with this client, I promise. ;)

> 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 ?

Of course. I also going to add some short doc about this feature.

Best regards,

                         Krzysztof Olêdzki Received on 2007/11/05 19:53