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
% 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
