Victor Duchovni put forth on 11/23/2010 11:05 PM: > On Tue, Nov 23, 2010 at 10:04:47PM -0600, Stan Hoeppner wrote: > >> I'm guessing the >> latency is actually higher when smtpd queries proxymap than when timing >> postmap -q. Is this the case? > > Not necessarily, it depends on how memory-constrained your system is. > Paging in a large table in a large number of parallel smtpd processes > may be more expensive than querying a consolidated table via IPC. > The IPC overhead is fractions of a millisecond. > > I would not use such a table, adding 0.5s of CPU for each client IP > lookup is to dear unless your traffic loads are *very* light. Surely > there's a better way! Have you considered rbldnd? The SpamHaus PBL > zone is a rather large CIDR table (in which all the reject messages > are one of two fixed templates in which the lookup key is embedded) > and it performs very nicely, since rbldnsd is able to query this > efficiently. You should consider an RBLDNS service instead of a large > CIDR table. Or find more effective data sources.
I disabled this table lookup earlier during our discussions while I was doing some other optimizations. In reality it's not too great an impact on my MX as the load is so low, but I just don't like that half second hit per transaction. This half second lookup delay is more a function of my hardware and the precompiled Debian binaries than the size of the CIDR table. The host in question is an old dual 500 MHz 686 class machine. On even relatively modern hardware such as a 2 GHz Opty running 64bit binaries these lookups would probably take less than 5 ms, instead of 500 ms. I implemented dnswl.org's CIDR table strictly to prevent some of my draconian A/S measures from blocking friendly mail, which has happened on more than a few occasions. Instead of using rbldnsd, I'm going to simply implement permit_dnswl_client once I move to 2.8. Timing digs to list.dnswl.org shows an average of about 100-200 ms latency, which although not great, is still 2.5 to 5 times quicker than my optimized version of their CIDR table. Speaking of upgrading to 2.8, I've always used the Debian Postfix packages. I'm guessing the next Debian release (Squeeze ETA Jan/Feb) will contain 2.6.5 or 2.7 but not 2.8. Can someone point me to a good set of instructions on compiling and installing from source, while keeping my current config files and updating them, and properly removing or bypassing the currently installed Debian 2.5.5 in a way that doesn't screw up the packaging system? Also, can any of the Postfix code paths benefit from integer MMX instructions if I can get GCC to use them? I would think SIMD instructions might be helpful with CIDR tables. If so, it will be interesting to compare before/after latencies. Thanks for the tips Viktor, Wietse. -- Stan
