Wietse Venema put forth on 11/24/2010 1:35 PM:
> 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

Thank you for the detailed explanation Wietse.  Given the low mail
volume of this MX (<2000 connections/day) would increasing max_idle from
100s to something like 5m or 10m be sane, to keep proxymap alive longer,
thus decreasing the frequency of table parsing, and thus total time per
query?  Would increasing ipc_idle above the default of 5s be beneficial?
 If so, how many seconds would you recommend for this MX given the low
volume?  If setting either of these to more than 6m, should I also
increase ipc_timeout to be greater than 3600s?

Thanks.

-- 
Stan



Reply via email to