Re: delta encoding and state management

[Willy Tarreau <[e-mail]>]

Hi Pat,

On Thu, Jan 24, 2013 at 09:50:34AM -0500, Patrick McManus wrote:
> On Thu, Jan 24, 2013 at 2:08 AM, Willy Tarreau <[e-mail]> wrote:
> 
> >
> > You don't count the trend in user count which is faster than the trend
> > in RAM price unfortunately. I've had several times people ask me what
> > to change in their kernel to go beyond 1 million concurrent connections
> > in haproxy. A few years ago, they were only talking about several tens
> > of thousands. With everything device connected to everything all the
> > time, I don't expect this trend to revert any time soon :-/
> >
> 
> Hey Wily,
> 
> you're a wicked smart guy with customers backed by millions of people and
> resources. Your problem is a "simple" (jokingly!) matter of engineering
> bigger systems.
> 
> The latency problem is inherent in the speed of light and can't be fixed in
> the same way. I remain convinced that it should trump other objectives when
> designing the protocol.
> 
> That being said, I'm not here arguing for RAM bloat! All I said is that if
> state can be justified by an improvement against the latency problem then
> it is truly justified. If another scheme can do the same with less state -
> then that's more awesome!

That's why I said that I'm not against adding *some* state. For example, even
if I would be really bothered by doubling the state size on middle boxes, it's
not always the end of the world. But it must be really justified and provide
substantial benefits. In my case, we're talking about adding few data. People
still doing pattern matching in HTTP on routers/firewalls will have a harder
time maintaining a state anyway. As time permits, I'll do my best to help
focusing on reducing costs for intermediaries (CPU and RAM) because they are
the ones making scaling possible and we must ensure we don't needlessly bloat
them.

Regards,
Willy