On Wed, Sep 13, 2000 at 01:27:57PM -0500, Jay Balakrishna wrote:
> Hi,
>
> Replies to your questions below.
>
> >I don't know how zmailer does it, but qmail, postfix and sendmail
> >all use a set*id program to protect their queue. (Does anyone know
> >whether zmailer does a fork/exec under the covers of the API?)
>
> No, it does not do a fork/exec under the covers. From my understanding
> of the zmailer code, mail_open() it opens a file under an intermediate
> queue directory called router and returns a FILE pointer for us to write the
> message. Then a seperate router process picks up the message
> from there. The advantage here is that there is very little over head in
> writing a file as opposed a popen("sendmail -i -t") call.
>
> >Have you measured that execing qmail-queue is "not very efficient" in
> >the full context of your system or are you surmising this?
>
> Yes, we have done a lot of timing analysis and it was found that in excess
> of 50% of the processing time is being spent in the code segment of the
> application that invokes the sendmail exe thro popen().
Erum, good, but did you measure the *total* cost of the email?
That includes the cost of the router process (in the case of zmailer) and
the qmail-send process (in the case of qmail) in picking up the email and
completing the queuing and delivery cost?
Sure, your insertion program may be 50% fork/exec, but if your
insertion program is 5% of the total load of the system, then you're
trying to tune a 2.5% problem. Actually, I'd expect that sort of outcome
regardless of the type of API or mailer, if your program does little
more than inject mail.
> We also explored
> the possibilities of using fork(), which is faster. But we are afraid that
> the system might run out of ulimit with all these small processes spawned.
That's an interesting conclusion. You see a popen() does exactly the
same thing. It fork/execs a shell which then fork/execs qmail-queue, so
popen() exacerbates your ulimit fear rather than alleviating it.
In other words your explorers need to look again as they got it exactly
around the wrong way.
As an aside, any ulimit fear is irrelevant if your insertion program
waits for the return from qmail-queue before submitting the next
mail as the ulimit applies to concurrent processes, not serially
created (and destroyed) ones.
> So now I understand why qmail does not have an API because otherwise
> the security is compromised. Thanks for your email.
Not quite. qmail doesn't have an API because no one has written one.
That API would simply call qmail-queue under the covers just as
the zmailer API calls fopen() under the covers.
Regards.
