On Friday 13 August 2010 19:58:38 Noel Jones wrote: > 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.
The OP did mention that if the email would be late, it wouldn't be of any use anymore. "Research reports are useless after the market opens" So I don't think he would mind loosing them if the power goes. But if he does, wouldn't a decent UPS with backup-to-disk of the queue during shutdown cover that? -- Joost
