Thanks Mark and Ian for your suggestion, I want ask again,
- Is queue runners like Incomingqueue runner so I have to make more Incomingqueue runner?
- How can I made more queue runners?
- Can I make more queue pipe so incoming email is deliver to pipe depend on their size and domain destination? 4 If I bombard my mailing list server using email stress test can I make a lot of waiting process in queue?
Thanks
---------- Forwarded message ---------- From: Ian Eiloart <iane@sussex.ac.uk> Date: 2008/6/4 Subject: Re: [Mailman-Developers] How To change queue process method To: Mark Sapiro <mark@msapiro.net>, Maickel Pandie <maickel.pandie@gmail.com>, mailman-developers@python.org
--On 3 June 2008 11:51:31 -0700 Mark Sapiro <mark@msapiro.net> wrote:
Maickel Pandie wrote:
I had research about how fast MTA (postfix) can deliver a lot of email from mailman. The one that I want to change is queue process method from FIFO to size based(sum of domain in the list x size of email), I have a list that contain the sum of domain each mailing list. I want Mailman prefer sending email that have less domain destination and small size of email.
Can you tell me what file I have to edit so mailman can decide what email is thrown to postfix first?
You would need to modify the Switchboard.files() method in module Mailman/Queue/Switchboard.py.
Think hard before you move away from FIFO queue processing. If your out queue is not backlogged, it will essentially be processed FIFO in any case because each time you look there will only be one or two entries to process. If it is backlogged and you process in any but FIFO order, you run the risk of leaving non-preferred entries unprocessed for very long times.
Also, your specific strategy would penalize larger (perhaps more popular) lists by delaying posts to those lists in favor of those to smaller (perhaps obscure) lists. Is this really what you want to do?
A better solution might be to configure Mailman to use more queue runners. We saw a massive performance increase when we did that, because a single large delivery would not hold up other quicker deliveries.
-- Ian Eiloart IT Services, University of Sussex x3148