[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transports directory
On Thu, 6 Jul 1995 Nicholas_Briggs.PARC@xerox.com wrote:
> It's not absolutely necessary, but it simplifies things somewhat. You should
> read the code rather than the ZMOG. While it might not be very difficult to
> eliminate one or the other, it is not *necessary* to do so, and is likely to
> result in more problems than it is solving (what problem are you trying to
> solve??). If you have time on your hands, and want to do something to
Reduce I/O requirements. From various reports, Sendmail puts less
demand on system's disk I/O than Zmailer does, handling the same volume of
mail. It is easy to see why. Sendmail, upon receipt of a message, saves
a control file and a message file in the queue, and when the message has
completed delivery, they are removed. Zmailer saves the message file in
the public directory, then moves it the router directory, then the router
moves it to the queue directory and writes a control file in the
scheduler directory. The scheduler moves the control file into a channel
directory and makes a link into the transports. As you can see, a fair
bit more disk activity.
There was a discussion of this on this list some time ago, about disk I/O
and Zmailer vs Sendmail.
> zmailer, IMHO it would be better spent reading and understanding the code and
> looking for bugs, security holes, performance problems, etc. rather than
> making what sound like gratuitous changes to working parts of the system.
I've been doing this. Right now the major weak area, appears to be the
scheduler. It has a memory leak (I had 13M scheduler process once). Now
this is with the 2.99.X code, but little seems to have changed in this
area. The scheduler should likely be rewritten with a higher system
standard (ex. os _must_ have select()).
> Sorry if this sounds somewhat curt, but I don't think change for change's sake
> is a good thing in software -- if there's a problem, solve it, if not, ...
This is most definitely not for "change's sake". I think that
shortening the path of message through Zmailer is a good idea. Right
now, the current message flow seems to be unnecessary complexity. If the
scheduler is to be re-written, it would probably make sense to go to a
I'm not suggesting that the old scheduler to be hacked
to do this. In fact if it was, it would probably cause massive
instabilities in the current scheduler that would take longer to debug
than a re-write.
To get an idea of where I going with this, I'd like to see the router
and scheduler use a more advanced form of process communication rather a
shared directory. Perhaps sockets, and just use the directory queues as a
fallback if a process becomes unresponsive (somewhat like the operation
or rnews on a INN system: if it can't pass the articles directly to
innd, queue in a incoming directory). However, I'd be the first to admit
that this is long way off, if it is going to happen at all.