[Mimedefang] performance tuning once again

[David F. Skoll]

tomvo at absi.be wrote:

> if the output of "md-mx-ctrl histo " command on the busiest time of the 
> day shows that let's half of the slaves have 0 messages scanned, does this 
> mean that i can safely lower (MX_MAXIMUM parameter)

Yes, probably.  But there's almost no benefit to lowering MX_MAXIMUM.
You should set MX_MAXIMUM so that if it's ever reached, your machine does
not swap.  If fewer than MX_MAXIMUM slaves are required, the multiplexor
won't start them.  (It only keeps MX_MINIMUM slaves around at all times.)

> I have implemented the following 'performance improving' features:
> - /var/spool/MIMEDefang on a ram disk
> - MX_EMBED_PERL=yes
> - spamassassin only checks message of  <100K

Those are all good.

> I am also using the multiplexor queuing using these parameters:
> # Multiplexor queue size -- default is 0 (no queueing)
> MX_QUEUE_SIZE=100

That's probably way too high.  If most of the time, you have fewer than
MX_MAXIMUM slaves, nothing will get queued anyway.

> My main concern is that every know and then,i get these dreaded 'timeout 
> before data read' errors (timeout of 10 minutes specified in sendmail.cf) 

That's weird.  It shouldn't be happening.

> # Number of seconds a process is allowed to scan an email before it is
> # considered dead.  The default is 30 seconds; we suggest 600.
> MX_BUSY=600

> What happens if this limit is exceeded ?

The multiplexor kills the slave and returns "please try again".

> I would like to configure my mail relay in such a way that, 
> when for some reason, the mail couldn't be scanned in time, the mail is 
> accepted anyway (because we have user's dropping mail directly to the mail 
> relay from their mail client's, and if they receive such a 'please try 
> again later' error, they get annoyed.

It's a bad idea to have mail clients connect directly to a machine running
MIMEDefang; best to have a dedicated mail-accepting machine that then relays
to the MIMEDefang machine.  Even if you could configure the machine to accept
mail in the event of a busy timeout, I think a 10-minute wait for the mail
server to respond would be pretty annoying. :-)

Regards,

David.