No need to worry about it. I manage systems with more than 6000 rules without any problem. In fact you'll need to worry just about disk I/O if all your rules use log and if the disk is not so fast. In case you have this problem you can always use:
pflogd_flags="-f /dev/null" in /etc/rc.conf.local, that way you'll still be able to debug with "tcpdump -i pflog0" without problems. Regards, Fabio Almeida On Wed, Jul 20, 2016 at 4:19 PM, Henning Brauer <[email protected]> wrote: > * Peus, Christoph <[email protected]> [2015-06-15 20:40]: > > I'm currently planning for a complete reorganization i.e. rewrite of a > > historically grown pf.conf of about 300 rules. Up to now each and every > rule > > uses the "quick" keyword, which effectively turns the "last match" > concept of > > pf into a "first match" one. Does that make any sense? > > mostly a matter of personal preference. quick performs slightly better > obviously; I highly doubt w/ just 300 rules you'll even get a > measurable difference tho. > > > Of course.. as evaluation stops at a matching rule with "quick" one may > expect > > that the average time it takes to decide whether a packet is passed or > blocked > > is significantly lower and therefore overall performance of pf will be > better > > with always using "quick". But is this true? > > depends on your definition of significant :) > > > Does this make sense if the CPUs > > are idling most of the time? Are there any rules of thumb when to use > "quick" > > and when to avoid it? > > in general, don't worry too much about performance impact from the way > you write your rules. in 99+% of the cases pf is so efficient that it > doesn't matter anyway, and the ruleset optimizer, skip steps et al do > their job so that you can concentrate on a ruleset optimized for the > human dealing with it, not the machine. > > -- > Henning Brauer, [email protected], [email protected] > BS Web Services GmbH, http://bsws.de, Full-Service ISP > Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully > Managed > Henning Brauer Consulting, http://henningbrauer.com/
