All of lore.kernel.org
 help / color / mirror / Atom feed
* iptables-restore vs iptables-restore --noflush performance
@ 2005-07-25 19:13 Joubert Berger
  2005-07-25 19:27 ` Steven M Campbell
  0 siblings, 1 reply; 3+ messages in thread
From: Joubert Berger @ 2005-07-25 19:13 UTC (permalink / raw)
  To: netfilter

Anyone know why I would get a big performance difference between
"iptables-restore" and "iptables-restore --noflush"?

I have 6600 rules.  If I load with iptables-restore, it takes about 30sec.
If I use noflush, that turns in 1 min and 20+ seconds.

--joubert


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: iptables-restore vs iptables-restore --noflush performance
  2005-07-25 19:13 iptables-restore vs iptables-restore --noflush performance Joubert Berger
@ 2005-07-25 19:27 ` Steven M Campbell
  2005-07-25 20:46   ` Joubert Berger
  0 siblings, 1 reply; 3+ messages in thread
From: Steven M Campbell @ 2005-07-25 19:27 UTC (permalink / raw)
  To: netfilter

Joubert Berger wrote:
>Anyone know why I would get a big performance difference between
>"iptables-restore" and "iptables-restore --noflush"?
>
>I have 6600 rules.  If I load with iptables-restore, it takes about 30sec.
>If I use noflush, that turns in 1 min and 20+ seconds.
>
>--joubert
>
>  
Because you have 6600 rules and when you use no-flush you are adding 
another 6600?  If you do it several
times in a row I'll bet the time keeps getting worse.

The insert time for each rule is, among other things, dependent on the 
number of rules that
must be searched/manipulated, thus an explanation for the times you see.

You should only use --noflush if you really intend to add rules to the 
current  rule set rather
than replace them all.  What are you trying to accomplish here?




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: iptables-restore vs iptables-restore --noflush performance
  2005-07-25 19:27 ` Steven M Campbell
@ 2005-07-25 20:46   ` Joubert Berger
  0 siblings, 0 replies; 3+ messages in thread
From: Joubert Berger @ 2005-07-25 20:46 UTC (permalink / raw)
  To: Steven M Campbell; +Cc: netfilter

Actually, what I do is load the first time the 6600 rules.  The next
time I load the 6600 rules, I load them using different chains.  At
the end, I just change FORWARD to point to the newly created chains
and then delete the old chains.

Are you saying, if I have 6600 rules loaded, no matter what chain I
add the next 6600 rules (i.e. totaly new chain), performance is going
to go up?  In other words, performance (inserting of rules) is tied to
# of total rules and not # of rules added to a chain?

TIA

--joubert


On 7/25/05, Steven M Campbell <Netfilter@scampbell.net> wrote:
> Joubert Berger wrote:
> >Anyone know why I would get a big performance difference between
> >"iptables-restore" and "iptables-restore --noflush"?
> >
> >I have 6600 rules.  If I load with iptables-restore, it takes about 30sec.
> >If I use noflush, that turns in 1 min and 20+ seconds.
> >
> >--joubert
> >
> >
> Because you have 6600 rules and when you use no-flush you are adding
> another 6600?  If you do it several
> times in a row I'll bet the time keeps getting worse.
> 
> The insert time for each rule is, among other things, dependent on the
> number of rules that
> must be searched/manipulated, thus an explanation for the times you see.
> 
> You should only use --noflush if you really intend to add rules to the
> current  rule set rather
> than replace them all.  What are you trying to accomplish here?
> 
> 
> 
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-07-25 20:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-25 19:13 iptables-restore vs iptables-restore --noflush performance Joubert Berger
2005-07-25 19:27 ` Steven M Campbell
2005-07-25 20:46   ` Joubert Berger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.