16. Optimizing list performance.

Ezmlm-idx is designed to make it as easy as possible to set up mailing lists. The default setup works well for small and medium-sized lists. For large lists, the lists can be made more efficient with a few simple changes.

16.1 Crond-generated digests for better performance.

With the default setup, ezmlm-tstdig(1) in dir/editor tests if a digest should be sent out. On lists with a lot of traffic this is inefficient. Also, you may want digests to be delivered as a specific time. To do this, use ezmlm-cron(1) or crond(8) to execute ezmlm-get(1) directly, as described elsewhere. See Disabling digest triggering by mail for more info on running ezmlm-get from crond(8).

ezmlm-warn(1).

ezmlm-warn(1) is executed once per message and once per administrative request. The program searches through the bounce directory to find bounces that are old enough to warrant warning or probe messages. This may take a lot of time if there are many bounces. It is more efficient to remove all the ezmlm-warn(1) lines from dir/editor and dir/manager and instead execute ezmlm-warn(1) via crond(8) at off-peak times. OIHO opinion, this is best done once per day at times when the mail system is least busy. Running it every 12 h or every 6 h, leads to smaller amount of mail per run, but the directory parsing is done two or four times, rather than once per day. (See Customizing bounce handling for more info on how to set this up.)

ezmlm-warn(1) time out to increase performance.

With ezmlm-idx, you may alter the ezmlm-warn(1) timeout to a number of seconds with the ``-t seconds'' switch. The default is 1,000,000 seconds or about 11.6 days. This is the time from the first bounce until ezmlm-warn(1) sends a warning message and the time from the warning message bounce until ezmlm-warn(1) sends a probe (which if bounced leads to removal of the address from the subscriber list). If you have a digest list, remember to execute ezmlm-warn(1) with the ``-d'' switch as well.

Decreasing the default to e.g. 5 days will cut in half the average number of files in the bounce directory and the number of messages sent at each crond(8)-directed invocation of ezmlm-warn(1). The trade-off is that worst case, a subscriber may be unsubscribed if his/her mail path is defective for more than twice the timeout. Removing a subscriber after 10 days seems reasonable on a busy list. Do this by adding the ``-t'' switch to all the ezmlm-warn(1) invocations. This timeout should be larger than the interval between ezmlm-warn(1) invocation.

If you have a digest list, remember to execute ezmlm-warn(1) with the ``-d'' switch as well. However, if the number of digest bounces is relatively small, you can use the default for this.

To be aggressive, use ``ezmlm-warn -t0''. This will minimize the time your lists spends servicing bounces, but will for some errors lead to subscribers to be also lead to subscribers being removed if messages to them bounce for two consecutive ezmlm-warn(1) runs.

16.4 Use ezmlm without ezmlm-idx for maximum performance.

ezmlm-idx adds a number of functions to ezmlm. It indexes the archive, and adds an index entry for each message, it can remove MIME parts, it can add a subject prefix and message trailer, decode rfc2047-encoded subjects, etc. Although designed to impact minimally on performance, these options when used take time. Even when they are not used, time is spent looking for e.g. the prefix. However, the performance penalty is small, as the absolutely dominating cost of a mailing list is the work qmail does to deliver the messages to subscribers.

Still, if you want maximal performance and do not need the features added by ezmlm-idx, it is better to use ezmlm alone.

You could also to ezmlm-0.53 add an individual program patched by ezmlm-idx. For instance, you can use the patched ezmlm-warn(1) to get access to the ``-t'' switch, even if all the other programs are ezmlm-0.53 only.

16.5 Not archiving to maximize performance.

An archived list needs to write the message to the archive. If you don't need an archive, don't archive. However, the archive is very useful to allow users to catch up on messages that they didn't receive due to delivery problems.

16.6 Sublists to maximize performance.

Consider splitting your list into sublists, ideally geographically. The main list deals only with a subset of subscribers (or only the sublists), and each sublist deals with a subset of subscribers, bounces, etc. This is the most rational way to scale ezmlm to large lists (see How sublists work for more info on how sublists work and Sublists on how to set up sublists).