On Fri, Aug 19, 2011 at 11:42:02AM -0400, Peter Blair wrote:
> On Fri, Aug 19, 2011 at 11:33 AM, Ram <[email protected]> wrote:
> > On 08/19/2011 07:50 PM, Reindl Harald wrote:
> >> Am 19.08.2011 16:05, schrieb Ram:
> >>>
> >>> I dont want to make smtpd connections in the app because that
> >>> slows down the app significantly and also this is a serialized
> >>> process. So sending mails serially slows down the general
> >>> delivery
> >>
> >> it is a bad design sending hughe bulk and "normal" mail-traffic
> >> with the same server/ip
> >>
> >> a) your slowing down problem
> >> b) reputation of this machine will be degraded sooner or later
> >>
> >>
> > Why reputation?
> > These are mails which partners pay to receive , not spam.
> > Also the numbers are not too huge. It could be 50k-100k mails
> > ..Only that they have to get sent ideally within 10 minutes .
>
> $ units
> 2411 units, 71 prefixes, 33 nonlinear units
>
> You have: 100000 seconds
> You want: 10 minutes
> * 166.66667
> / 0.006
>
> Unless my quick math is wrong, that's 166 mail messages per second.
> I think that if you're worried about your harddrives not being up
> to snuff, you probably won't be sustaining these kinds of numbers.
> Especially if the message sizes are larger (ie, containing those
> base64 encoded attachments).
>
> Back to reputation, just because the recipient mailbox owner wants
> the mail, doesn't mean that the mailbox-owner's postmast will want
> the mail if you're bursting a lot of messages to multiple
> recipients under the same domain. "Burstiness" == "spaminess" in
> certain circles.
>
> If you're serious about this customer, consider placing them on
> a dedicated postfix instance,
Yes, agreed.
> and if you're worried about IO latency, consider mounting the
> active queue as a tmpfs or ramdisk if you're system can support
> that VM-wise. But, that can be dangerous, since you will lose
> mail if your system goes down while a message is in a volatile
> storage mount.
I wouldn't do it this way, for the very reason you gave. A safer
option is to have the mail-generating software use the ramdisk.
Presumably, that software could run again and regenerate any lost
mails, and the Postfix logs would show exactly which ones were
created and sent.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header