Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.2.0, 2.3.0, 2.3.1, 2.3.2, 3.0.0, Trunk
-
None
-
nothing fancy, but network latency may be a contributing factor
Description
the following are sample mean timings from the InSpammerBlacklist matcher:
all requests were for 127.0.0.1
hostname - lookup count - mean timing - this lookup time
1.0.0.127.query.bondedsender.org. - 10.0 - 71.9 - 16.0
1.0.0.127.dnsbl.njabl.org. - 10.0 - 265.6 - 266.0
1.0.0.127.relays.ordb.org. - 10.0 - 20095.6 - 20172.0
As you can see they all take signifcant time, and ordb.org is painful.
Of course "success" of the matcher is !success of the lookup, which means that while we will cache the hits they are only the failures, and the good mail will have to perform a full ns lookup everytime.
We should think about caching the successes locally, or arranging these mailets in a separate processor and having independantly threaded processors.
In this case (ten mails) each thread paused for 20 seconds waiting for ordb and then continued, making the whole thing pause for 20. But because I was running 10 spool threads when I increased this to 20 mails the threads paused twice, meaning that the 21st message took 40+ seconds to complete its journey through the spoolmanager.
Not good.
Workaround, don't use InSpammerBlacklist or set it up in a processor so that it is called by ToProcessor only on classes of mail for which the expense is justified (e.g. not on any outbound or on trusted IP's, senders or domains)
Attachments
Issue Links
- relates to
-
-
- Resolved
-
1.
|
Remove ordb.org from docs |
|
Closed | Norman Maurer |