First off, all the SMTP-handling code is in C. That's got to be less resource-intensive than perl.
Not when I tested it. It's hard to accurately benchmark just the SMTP-talking part of an MTA, so I'll not claim those tests were perfect, but accepting multiple emails using Net::Server::Mail did not take significantly longer nor use more memory than doing so with a regular MTA.
Second, it's already written, most bugs worked out, and someone else will fix any new bugs found.
The same is true of Net::Server::Mail.
Regarding the comparative resource-intensiveness of multiple perl processes versus a daemon, I think you're forgetting copy-on-write. You're right in that the OS will almost certainly keep modules in the disk cache if they are called multiple times by quickly-spawning processes. However, the OS still has to create a new process and address space, compile the Perl code and fill the new process memory with it. Do that several thousand times within a second and you will run out of memory even on beefy machines. With a perl daemon that forks off instances of itself, the OS uses COW for the process address space, which means that real memory consumption is far lower.
Another point not mentioned yet is resource consumption limiting. If you have qmail spawning processes you have very little control over how many processes are created simultaneously. This can be especially fatal if your database connection is slow or some other resource is blocking, your OS will simply create processes too fast for the machine to handle and crash. This can be circumvented by using ulimit or PAM, but both of these have drawbacks, are not failsafe and far more complicated than simply setting max_servers in Net::Server::PreFork.
In reply to Re^4: Simple (but robust) email server (receiver)
by tirwhan
in thread Simple (but robust) email server (receiver)
by zby
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |