diff options
Diffstat (limited to 'contrib/sendmail/src/TUNING')
| -rw-r--r-- | contrib/sendmail/src/TUNING | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/contrib/sendmail/src/TUNING b/contrib/sendmail/src/TUNING index 6ccff9a..fe9e694 100644 --- a/contrib/sendmail/src/TUNING +++ b/contrib/sendmail/src/TUNING @@ -5,7 +5,7 @@ # forth in the LICENSE file which can be found at the top level of # the sendmail distribution. # -# $Id: TUNING,v 1.19 2003/01/25 23:06:02 ca Exp $ +# $Id: TUNING,v 1.21 2006/09/25 16:45:05 ca Exp $ # ******************************************** @@ -39,7 +39,7 @@ Depending on your requirements, these may need different options to optimize sendmail for the particular purpose. It is also possible to configure sendmail to achieve good performance in all cases, but it will not be optimal for any specific purpose. For example, it -is non-trivival to combine low latency (fast delivery of incoming +is non-trivial to combine low latency (fast delivery of incoming mail) with high overall throughput. Before we explore the different scenarios, a basic discussion about @@ -49,7 +49,7 @@ disk I/O, delivery modes, and queue control is required. * Disk I/O ----------------------------------------------- -In general mail will be written to disk up before a delivery attempt +In general mail will be written to disk before a delivery attempt is made. This is required for reliability and should only be changed in a few specific cases that are mentioned later on. To achieve better disk I/O performance the queue directories can be spread @@ -76,7 +76,7 @@ interactive: incoming mail will be immediately delivered by the same process queue: incoming mail will be queued and delivered by a queue runner later on The first offers the lowest latency without the disadvantage of the -second, which keep the connection from the sender open until the +second, which keeps the connection from the sender open until the delivery to the next hop succeeded or failed. However, it does not allow for a good control over the number of delivery processes other than limiting the total number of direct children of the daemon @@ -95,7 +95,7 @@ other two modes. However, this mode is probably also best for concurrent delivery since the number of queue runners can be specified on a queue group basis. Persistent queue runners (-qp) can be used to minimize the overhead for creating processes because they just -sleep for the specified interval (which shold be short) instead of +sleep for the specified interval (which should be short) instead of exiting after a queue run. @@ -139,7 +139,7 @@ should be added to the .mc file. * Mailing Lists and Large Aliases (1-n Mailing) ----------------------------------------------- -Before 8.12 sendmail delivers an e-mail sequentially to all its +Before 8.12 sendmail would deliver an e-mail sequentially to all its recipients. For mailing lists or large aliases the overall delivery time can be substantial, especially if some of the recipients are located at hosts that are slow to accept e-mail. Some mailing list @@ -148,9 +148,9 @@ fewer recipients. sendmail 8.12 can do this itself, either across queue groups or within a queue directory. The latter is controlled by the 'r=' field of a queue group declaration. -Let's assume a simple example: a mailing lists where most of -the recipients are at three domains: the local one (local.domain) -and two remotes (one.domain, two.domain) and the rest is splittered +Let's assume a simple example: a mailing list where most of the +recipients are at three domains: the local one (local.domain) and +two remotes (one.domain, two.domain) and the rest is splittered over several other domains. For this case it is useful to specify three queue groups: @@ -209,10 +209,10 @@ For high volume mail it is necessary to be able to control the load on the system. Therefore the 'queue' delivery mode should be used, and all options related to number of processes and the load should be set to reasonable values. It is important not to accept mail -faster than it can be delivered otherwise the system will be +faster than it can be delivered; otherwise the system will be overwhelmed. Hence RefuseLA should be lower than QueueLA, the number of daemon children should probably be lower than the number of queue -runnners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option +runners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option in 8.12 which allows delaying connections instead of rejecting them. This may result in a smoother load distribution depending on how the mails are submitted to sendmail. |
