On Tue, Jun 01, 2010 at 01:56:37PM +0200, Jan Engelhardt wrote: > >Whole iptables ruleset is represented by few files in /etc. Some of them > >are generated, some of them are hand written. I am able to feed /etc > >rules to iptables-restore or execute them as shell script. This is > >trivial. Although iptables-restore is faster than executing iptables in > >shell script, it is still very slow sometimes. > > > >Changes in /etc ruleset are small but frequent. But primarily both > >solutions reset couters if used and it is not good for me now. So I > >ended with script that does incremental updates. > > How slow are we talking about? restore is never slower than > iptables - ever, because, like iptables, it does one table replace > operation per invocation of either binary. Your "incremental update" > is in fact none, because tables are always replaced wholesome. I know that iptables-restore with 10000 rules on input is faster than 10000 sequential "iptables -A ..." rules. It is obvious. But anyway it is sometimes slower than my one "iptables -D" command followed by one "iptables -A" command that both together reflect one particular change in ruleset that I am able to recognize with rule comparison. Especially under higher load. Reason is not obvious. I was forced also implement my own locking and memoization around iptables-save that prevents its concurrent invocation from accounting process. The accounting is simple - it transfers output to accounting machinge. That caused troubles in the past when I used to see hanging iptables-save/-restore processes. Maybe some locking issues? It is hard to reproduce or debug for me. We use Debian Etch and Lenny mainly without any kernel or netfilter customization. I wanted to discuss this theme before I will start to prepare incremental updates for tc configuration. It is even worse as restart takes routinely 1 or 2 minutes and there is no tc-restore mechanism and tc output is totally different from its input. Also note that my problem is not performance of packet filtering. It is OK. Regards Radek Kanovsky -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
