<br><br><div class="gmail_quote">On Wed, Jun 3, 2009 at 1:58 PM, Martin Hepworth <span dir="ltr"><<a href="mailto:maxsec@gmail.com">maxsec@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
more children will help - alot of this is suck it and see as<br>
performance can vary alot. normal starting point is 5 children per<br>
core and 30 messages per batch.</blockquote><div><br>I am currently running 45 processes and around 25 messages per batch. Will try to tweak and see.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
for that sort of level I'd be looking at multiple machines - if you<br>
loose this machine or whatever reason what happens!<br>
</blockquote><div><br>Getting 2 more for performance and redundancy reasons <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also check the RBL's you're running - things like spamhaus will<br>
require a licence for thsi sort of amount and too RBLs slows the<br>
processing down alot.</blockquote><div><br>I am considering that. Running a local caching server will help limit the number of queries made but will definitely look into that. I remember reading about Ironport's architecture docs mentioning that it uses an asynchronous kernel. Has anyone played with the 2.6 kernel scheduler?<br>
<br> <br></div>--<br>Zaeem<br></div><br>