[jira] Resolved: (JAMES-758) InSpammerBlacklist latency seriously affects throughput

["Norman Maurer (JIRA)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/JAMES-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Norman Maurer resolved JAMES-758.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0-M1

was removed from config.xml

> InSpammerBlacklist latency seriously affects throughput
> -------------------------------------------------------
>
>                 Key: JAMES-758
>                 URL: https://issues.apache.org/jira/browse/JAMES-758
>             Project: JAMES Server
>          Issue Type: Improvement
>          Components: DNSServer, Matchers/Mailets (bundled), SpoolManager & Processors
>    Affects Versions: 2.2.0, 2.3.0, 2.3.1, 2.3.2, 3.0, Trunk
>         Environment: nothing fancy, but network latency may be a contributing factor
>            Reporter: Danny Angus
>            Assignee: Danny Angus
>             Fix For: 3.0-M1
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org