You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2007/01/18 11:00:30 UTC
[jira] Commented: (JAMES-758) InSpammerBlacklist latency seriously
affects throughput
[ https://issues.apache.org/jira/browse/JAMES-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465701 ]
Stefano Bagnara commented on JAMES-758:
---------------------------------------
I didn't see this issue before: today I had to remove "relays.ordb.org." from my config.xml in order to let my mail to pass through. I had thousands of mails waiting for dns resolutions.
I think this is getting critical and we should probably change our default config.xml to remove by default that mailet and to add a comment about current timings of that hosts.
> InSpammerBlacklist latency seriously affects throughput
> -------------------------------------------------------
>
> Key: JAMES-758
> URL: https://issues.apache.org/jira/browse/JAMES-758
> Project: James
> Issue Type: Improvement
> Components: DNSServer, Matchers/Mailets (bundled), SpoolManager & Processors
> Affects Versions: 2.2.0, 2.3.0, 2.3.1-dev, Next Minor, Next Major, Trunk
> Environment: nothing fancy, but network latency may be a contributing factor
> Reporter: Danny Angus
> Assigned To: Danny Angus
>
> 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)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org