Some text was lost ruring cut-and-paste. I have added it below.

        Wietse

Stan Hoeppner:
> Wietse Venema put forth on 11/24/2010 6:18 AM:
> 
> > That's 0.5 seconds to read the table once, and milliseconds to query it.
> 
> Is it?  I must be misreading this then.  But it sure looks like each
> query is taking over half a second.
> 
> Table has 67669 CIDRs:
> 
> [r...@greer]/etc/postfix/cidr_files$ time postmap -q 1.1.1.1 cidr:dnswl
> 
> real    0m0.618s
> user    0m0.464s
> sys     0m0.064s

Below are results that show that some 99% of those 0.6 seconds are
spent compiling the table, and some 1% is spent matching the table.

Postfix daemons handle multiple queries during the process lifetime.
Therefore the typical query latency for a Postfix daemon is much,
much, smaller than your 0.6 seconds.

Below, I create a table of 1638400 patterns, then compile+query it
once for an address that does not match the table in 1.62s, then
compile+query it 11 times for that address in 1.83s.

Notice that the two times are almost the same.   With a little
math we get:

time-to-match = (1.83 - 1.62) / 10 = 0.021s
time-to-parse = 1.62 - 0.021 = 1.60s

In other words, the time-to-match is roughly 1% of the time-to-parse.
The time-to-match is more representative of Postfix daemon latency
because it handles multiple queries during the process lifetime.

        Wietse

% cat mkcidr.pl
#!/usr/bin/perl

for $first (0..255) {
    for $second(0..255) {
        for $third(0..25) {
            print "$first.$second.$third.1      whatever\n";
        }
    }
}
% perl mkcidr.pl > table.cidr
% cat mkquery.pl
#!/usr/bin/perl

for $first (0..255) {
    for $second(0..255) {
        for $third(0..25) {
            print "$first.$second.$third.1\n";
        }
    }
}
% perl mkquery.pl > queries.txt
% time postmap -q 1.2.3.4 cidr:table.cidr
        1.62 real         1.44 user         0.17 sys
% yes 1.2.3.4 | sed 11q | time postmap -q - cidr:table.cidr >/dev/null
        1.83 real         1.68 user         0.13 sys



Reply via email to