On Sun, Jul 21, 2013 at 11:15:19PM +0200, Cyril Bonté wrote: > >First, I think that we should only focus on 1.5 at the moment, as it > >changed too much from 1.4 to have a general solution. If we find a > >way to make this work nice in 1.5, then we'll more easily consider > >whether we want to try to use the same for 1.4 or if we'd rather leave > >it as it is now. And if we find no elegant enough solution (I mean none > >which does not make the lower layers aware of the upper), then maybe the > >solution will be to have a specific option for this behaviour. > > It's not heavily tested but I was thinking about such a patch (in > attachment). It looks to work with/without splicing. > Originally, the feature claimed to impact the performance about 0.5%, > but as haproxy 1.5 introduced stick tables, I'm not sure about this > (session_process_counters does more than it was in 1.3). > > Downloading a 1GB file across a gigabit ethernet lan with splicing > enabled and option contstats, counters were updated 68043 times. > The same without splicing, counters were updated 86798 times.
That's where I'm trying to be very careful. On a 10 Gbps link, this means 68/86k updates per second on something not cheap. > The drawback is that stream_interface has to know about the session > (wich is already provided in the structures). Yes that's something that I don't feel very happy with, because we managed to progressively remove the high level knowledge from the lower layers, and we're going to reintroduce it. But I clearly forgot about the stick table counters, so we can't even have a generic stats interface that the stream_interface would update. Or we could have the session register a function pointer on the s.i. but calling this function would probably be even slightly worse in terms of performance. However it could preserve the layering model. As you can see I'm a bit undecided on this, I think some more thinking is needed. For example, maybe we're taking the problem the wrong way, and we should have the stream_interface and only them updating a small set of counters at the frontend/backend level, and we'd have the session update the stick table counters. That's just an idea, it may be stupid in the end, I don't know yet. Regards, Willy
