Performance problem of tproxy
Dear all, I test the performance of TPROXY (cttproxy-2.4.20-14) on a dual XEON, Giga-bit machine. The environment setting is: Client <-------> Proxy <---------> Server #1: With TPROXY, fully transparent (both to client and to server) #2: Without TPROXY, no transparency, client connects to proxy directly. #3: With iptables built-in REDIRECT, Half transparent (to client only) #4: With TPROXY, Half transparent (to client only) The results are: #1: 184 Mbits/s #2: 671 Mbits/s #3: 554 Mbits/s #4: 551 Mbits/s From #2 and #4, the overhead of one NAT is 120 Mbits/s. #1 (fully transparency) is too bad....It should be around 430 Mbits (671 - 120 * 2 since two NATs ) Does anyone know why the performance drops so drastically when using fully-transparency??? Thanks, Eric Li __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
Hi, 2005-02-02, sze keltezéssel 08.11-kor Siming Li ezt írta:
From #2 and #4, the overhead of one NAT is 120 Mbits/s.
#1 (fully transparency) is too bad....It should be around 430 Mbits (671 - 120 * 2 since two NATs )
Does anyone know why the performance drops so drastically when using fully-transparency???
Hmm, good question. I have to admit that I did not do such performance tests (yet), but the version you're using is quite old -- I'd even say it's from the stone age :). Would it be possible for you to try a bit more up-to-date version and see if its behaviour is the same? (1.2.1, for example.) -- Regards, Krisztian Kovacs
Due to lots of system code depending on kernel 2.4.20, so it's not easy for me to try the latest vresion right away. From the view of tproxy source code, what's the extra effort when using foreign-connect? (more conntrack or NAT lookup?) It may give me so hints about this problem. --- Regards, Siming --- KOVACS Krisztian <hidden@balabit.hu> wrote:
Hmm, good question. I have to admit that I did not do such performance tests (yet), but the version you're using is quite old -- I'd even say it's from the stone age :). Would it be possible for you to try a bit more up-to-date version and see if its behaviour is the same? (1.2.1, for example.)
-- Regards, Krisztian Kovacs
__________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Hi, 2005-02-03, cs keltezéssel 00.00-kor Siming Li ezt írta:
Due to lots of system code depending on kernel 2.4.20, so it's not easy for me to try the latest vresion right away.
From the view of tproxy source code, what's the extra effort when using foreign-connect? (more conntrack or NAT lookup?) It may give me so hints about this problem.
Theoretically it's one extra hash lookup per connection (tproxy has its own hashtable). However, older versions of tproxy scanned the whole conntrack table on connection teardown, so it may be perfectly possible that this is the culprit in your case. The version you're using is really, really old, newer versions have fixed lots of bugs. This is why I suggested trying 1.2.1 instead of trying to fix that old version - probably you don't need that many changes to backport the 1.2.1 version. (A release for 2.4.22 is available.) -- Regards, Krisztian Kovacs
participants (2)
-
KOVACS Krisztian
-
Siming Li