Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Noel Jones (njonesmegan.vbhcs.org)
Date: Fri Aug 13 2010 - 12:58:38 CDT
On 8/13/2010 8:22 AM, J. Roeleveld wrote:
> On Friday 13 August 2010 14:23:51 Wietse Venema wrote:
>> Ralf Hildebrandt:
>>> * Ram<ramnetcore.co.in>:
>>>> Mail in plain text format , mime encoded message
>>>> 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.
> 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