Re: performance issues (nat / conntrack)

[Patrick Schaaf <bof@bof.de>]

Don,

(hope you don't mind me replying on-list)

On Sun, Jun 23, 2002 at 11:30:13PM -0700, Don Cohen wrote:
> Patrick Schaaf writes:
>  > Nevertheless, it does point out a valid optimization chance. We discussed
>  > that months ago, and it's still there.
> What's that?

Looking at the quality of the hash function used, and improving it.

> 
>  > In the real world, nobody seems to care. I know I don't, and I really
>  > looked. It doesn't matter.
> I'm really lost here.  What doesn't matter?

The relative slowness of conntrack vs. nonconntrack doesn't matter in the
real world. I can reproduce it in artificial tests, but in reality, the
arrival rates for new connections are lower. The reason, at least for me,
is that I parallelize on multiple boxes long before conntrack reaches its
breaking point, and I do that for different reasons (resilience and the
other workload the boxes tend to have, like user level proxying.)

>  > As for theories, the last time, we almost agreed that the hash function
>  > is very bad. Nobody did confirm that feeling, though.
> What's wrong with the hash function?

It's suspected to be bad. Chains are suspected to become long. Bucket
occupation is suspected to have high variance. Nobody checked, or at
least nobody reported the results of such checking.

best regards
  Patrick