On 8/13/2010 8:22 AM, J. Roeleveld wrote:
On Friday 13 August 2010 14:23:51 Wietse Venema wrote:
Ralf Hildebrandt:
* Ram<r...@netcore.co.in>:
Mail in plain text format , mime encoded message
OK!
Currenlty I get 40/s - 45/s
That sounds normal. Any filtering (in these cases you should inject in
a way that bypasses and filters)
But I want it to be atleast 100/s
Two machineS?
relay boxes
Delivery is not at all an issue , because postfix gives it to further
relay boxes which are under our control again.
Why not inject to the further relay boxes?
Do I need to increase the hardware
It could be :)
Other options: increase input concurrency, or play with in_flow_delay.
Note that increasing your input rates will cause output rates to drop.
It's all about competing for disk access.
Wietse
Further options, I think:
- Disable filtering (provided the only possible connections are related to
these emails
Presumably the client would be in mynetworks, which should
bypass most or all restrictions, so this is unlikely to make
much difference. Unless you're doing something silly like
1000 body_check rules or using a content_filter or milter.
- put the queue on a ram-disk (8GB Ram, might leave 6GB for the queue, would
this be sufficient?)
Putting the queue on ramdisk is only for spammers who don't
particularly care if their mail is lost.
But putting the queue on an enterprise-quality SSD would
almost certainly help.
-- Noel Jones
