Fri, 21 Jul 2000 09:06:16 +0200 (MEST)
after short, very unscientific tests I just did, I think that in the
future, we can answer "how much does netfilter conntracking cost"
with a resounding "nada".
I'm testing two dual Katmai 500Mhz boxes, both connected through one
SK98 1000baseX cards to a Catalyst 6509 switch. Kernel is test5-pre1.
On one box, a very minimalistic HTTP server runs (two processes,
poll() based, loadsharing), and serves three very static files
(300 byte, 14KB, 1MB). On the other box, I run two or four processes,
each making requests (8 or 16 per process in parallel), onto that server.
Each test run consists, for example, of a total of 40000 requests (each
a new HTTP connection) to the server, thus nicely overflowing the 30000
entry conntrack table.
Comparing the measurements with or without conntrack, I see no significant
difference in the runtimes or CPU usage. What I did so far is not really
scientifically sound (maybe later), but very very promising.
If you are curious: I manage about 5500 HTTP req/s for the 300 byte requests,
and an aggregate throughput of ~75MB/s, using 9000 byte MTU, when requesting
the 1MB file. For the large file test, there's even about one CPU left idle...
A big thumbs up to the netfilter team, the TCP stack hackers, and everybody
else who made this possible!