in reply to Re: Re: Net::SMTP slow on linux
in thread Net::SMTP slow on linux

You are correct. Postfix (and MTAs in general) are extremely disk IO intensive. If you're looking into improving performance of the system, I recomend you look into a faster disk subsystem. A lot of work can be done tweaking Postfix for optimal performance too (running a second instance for defered emails, tuning the # of processes and SMTP timeouts, moving spools onto their own disks (or at least separate partitions), if you're willing to risk loosing data in the event of a power outage you can also try using a ramdisk for spool, etc...)

You may be able to squeeze a little more performance out of your existing system by generating (and delivery to postfix) mails in parallel. I was running on a e450 for a while with 4 CPUs and postfix and I found that my optimal generation rate was produced by having 8 simultaneoue mail generation/injection processes. Your performance may vary, but its worth looking into. If you try this, be careful not to flood postfix's mailqueues. If they grow too large performance will suffer.

Replies are listed 'Best First'.
Re: Re: Re: Re: Net::SMTP slow on linux
by shadowpuppet (Acolyte) on Apr 22, 2002 at 19:24 UTC
    Yes, the generating in parallel was something we discovered as well. Although the max injection rate (SMTP submits) we could get out of a process was 250,000 per hour, we discovered that doing 2 at a time didn't slow down this rate much. We were thinking of running 4 at a time on each server. But I'll trust and suggest your number 8 - that makes sense. If I can linux to submit at 250,000 by putting it on EMC array (which is like ram disk), we'll be in business with multiple processes. On a side note, the 250,000 was up from 125,000 when I made the following code change on Net::Cmd ->
    line 476__  $main::ignore_response ? 1 : ($cmd->response == CMD_OK);

    [download]

    I noticed alot of delay in waiting for the response when a mail was finished submitting to postfix. I set ignore_response as a global in the sending program.

    Thanks for your help and confirmation of the multiple-processes strategy.
    --Jim

[reply]
[d/l]

In Section Seekers of Perl Wisdom