- Mar 25, 2013
On 3/25/2013 8:52 AM, Noel Jones wrote:
>>> are you missing http://www.hardwarefreak.com/fqrdns.pcre ? :)
>> very interesting link, as I understand my postfix is not prepared for
>> pcre thus I won't be able to use it, right?
> You can use this file as a regexp: type.
> pcre is recommended as it's a little faster than the built-in regexp
> library on most systems.
The table was created many years ago over an extended period of time, by
staff at a US ISP, composed of fully qualified POSIX regular
expressions, some 1400 or so, and used with the Postfix REGEXP facility.
When I began maintaining it and offering it publicly some years ago I
cleaned up a few errors so it would execute via Postfix PCRE, which is
faster as Noel mentions. This is why I publish the file with a .pcre
extension and recommend it be used this way.
The few hundred expressions I've added should also be POSIX regex
compliant. Thus it should still execute just fine via the Postfix
REGEXP facility, albeit slightly slower. How much slower? On modern
hardware the table easily fits in L2/L3 cache. With only ~1700
expressions, about half of these being skipped on each pass due to
conditional tests, the difference between PCRE and REGEXP processing
time will be something like up to a few 10s of microseconds.
Thus one may ask, "Why does it really matter then?" On a low volume
server it makes no difference. However, on a high volume server the
execution time of all combined restrictions adds up quickly, and if the
server is doing content analysis (SpamAssassin) that burns a ton of CPU.
Thus it's best to keep individual table execution time to a minimum.
This is also why the table uses mostly fully qualified expressions.
Each requires far fewer CPU instructions than wildcard matching.
- << Previous post in topic Next post in topic >>