Brandon Applegate:
> In any case - I've been wondering about the potential performance
> impact related to the size of the cidr_client_checks file. I
> currently have ~ 600 networks listed there. I haven't noticed
> anything yet - but would like to know if there's a size where I
> should worry. I've pruned the oldest entries from here in the
> past (assuming plenty of time to get them added to an RBL) - but
> if there's no foreseeable performance impact - I'd like to not
> worry about keeping it pruned.
Postfix CIDR maps have two sources of overhead.
1) The one-time overhead to read and parse a CIDR map file. Postfix
daemon processes handle up to 100 client sessions. That reduces the
cost of initialization.
2) The per-query overhead, which depends on how many patterns need
to be examined before a match is found. This depends on the query
and on the ordering of patterns in the map. These are simple binary
"AND" operations, and they should be fast. The postscreen daemon
relies on that.
You can measure both overheads with postmap.
To measure initialization overhead, look at the difference between
$ time postmap -q /dev/null static:foo
$ time postmap -q /dev/null pcre:yourfile
You will probably have to run this several times to get a meaningful
result.
A quick experiment on an old server (i5-650 processor@3.2GHZ) shows
that it takes 0.15s to parse a 100 thousand patterns. Matching those
patterns should be much, much, faster.
Wietse
