Things affecting on ZMailer performance

These tidbits have been learned at various systems, when trying to get an undersized machine to do amazing feats.

NFS:

If you for some obscure reason are mounting MAILBOXes and/or POSTOFFICE hierarchies via NFS, do it with options to disable various attribute caches:

  actimeo=0
  noac

The best advice is to not to mount anything over NFS, but some people can't be persuaded... Lots of things are done where file attributes play important role, and they are extremely important to be in sync! (Sure, the 'noac' slows down the system, but avoids errors caused by bad caches..)

If you are mounting people's home directories ( .forward et.al. ) via NFS, consider the same rule!

Router:

• DNS, and other database lookups (primarily the DNS!)
• If possible, do not do DNS lookups at the router at all. Handle the DNS queries at the SMTP transporters
• Use of keyed databased (ndbm, gdbm) is way faster, than unordered linear search, or even ordered binary search as is used at some databases (aliases, for example.) For small databases, an incore database is faster, especially if its altered rarely. (Like a list of the top-level domains)
• DNS server must have large caches, and be able to cache negative answers / timeouts too!
• System speed on directory access (filesystem speed) (scanning the directory, and doing stat() is SLOW on some platforms! Especially if trying to have files sorted into time-order before processing them...)

Scheduler:

• System speed on directory access (filesystem speed) (scanning the directory, and doing stat() is SLOW on some platforms! ==> Can cause very slow startup if queue is long..)
• Usage of hashed spool-areas ($POSTOFFICE/queue/X/file, $POSTOFFICE/transport/X/file) shrinks the average size of the directory, and thus access fill be faster
• Speed to do inter-process communication via PIPEs ( on platforms that can do it: socketpair() )
• Speed of filesystem access for message control file parsing (on some systems apparenly equally "costly" as simply doing a stat() on the file -- amazing .. .. that is, the stat() is amazingly costly...)
• Speed of scheduler's mux() scanning thru all transporter's reporting channels (This can be alleviated by use of ``overfeed=nnn'' configuration option, and thus feeding the pipe full of jobs..)

Transporters:

• Speed to do IPC via PIPEs
• System speed on opening files
• DNS lookup for SMTP connection setups
• Remote IPC over TCP/IP
• Local filesystem access speed (read spool files, write mailboxes..)
• Idleness in between scheduler passes at our report channel, and before the scheduler feeds more jobs