|
|
|
|
||||||
| comp.mail.sendmail Configuring and using the BSD sendmail agent. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
In a busy server with thousands of outbound connections, is it possible to
somehow group those connections better by domain? IE, make sendmail realize that there are a bunch of messages for domain A and if possible send those with one connection to the respective domain? Regards, -pa |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
Paul Aviles wrote: > In a busy server with thousands of outbound connections, is it possible to > somehow group those connections better by domain? IE, make sendmail realize > that there are a bunch of messages for domain A and if possible send those > with one connection to the respective domain? > > Regards, > > -pa >From doc/op 4.10. Connection Caching When processing the queue, sendmail will try to keep the last few open connections open to avoid startup and shutdown costs. This only applies to IPC and LPC connections. When trying to open a connection the cache is first searched. If an open connection is found, it is probed to see if it is still active by sending a RSET command. It is not an error if this fails; instead, the connection is closed and reopened. Two parameters control the connection cache. The ConnectionCacheSize (k) option defines the number of simultaneous open connections that will be permitted. If it is set to zero, connections will be closed as quickly as possible. The default is one. This should be set as appropriate for your system size; it will limit the amount of system resources that sendmail will use during queue runs. Never set this higher than 4. The ConnectionCacheTimeout (K) option specifies the maximum time that any cached connection will be permitted to idle. When the idle time exceeds this value the connection is closed. This number should be small (under ten minutes) to prevent you from grabbing too many resources from other hosts. The default is five minutes. And also from doc/op QueueSortOrder=algorithm [no short name] Sets the algorithm used for sorting the queue. Only the first character of the value is used. Legal values are "host" (to order by the name of the first host name of the first recipient), "file- name" (to order by the name of the queue file name), "time" (to order by the submis- sion/creation time), "random" (to order ran- domly), "modification" (to order by the mod- ification time of the qf file (older entries first)), "none" (to not order), and "prior- ity" (to order by message priority). Host ordering makes better use of the connection cache, but may tend to process low priority messages that go to a single host over high priority messages that go to several hosts; it probably shouldn't be used on slow net- work links. Filename and modification time ordering saves the overhead of reading all of the queued items before starting the queue run. Creation (submission) time ordering is almost always a bad idea, since it allows large, bulk mail to go out before smaller, personal mail, but may have appli- cability on some hosts with very fast con- nections. Random is useful if several queue runners are started by hand which try to drain the same queue since odds are they will be working on different parts of the queue at the same time. Priority ordering is the default. |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
"jmaimon@ttec.com" <jmaimon@ttec.com> writes:
> Paul Aviles wrote: >> In a busy server with thousands of outbound connections, is it possible to >> somehow group those connections better by domain? IE, make sendmail realize >> that there are a bunch of messages for domain A and if possible send those >> with one connection to the respective domain? >> >> Regards, >> >> -pa > >>From doc/op > > 4.10. Connection Caching > > When processing the queue, sendmail will try to > keep the last few open connections open to avoid > startup and shutdown costs. This only applies to IPC > and LPC connections. > [...] Sendmail by default uses DeliveryMode=backgroud and delivers most messages at once *WITHOUT* "processing the queue". -- [pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
Andrzej Adam Filip wrote: > "jmaimon@ttec.com" <jmaimon@ttec.com> writes: > > Sendmail by default uses DeliveryMode=backgroud and delivers most > messages at once *WITHOUT* "processing the queue". > Yes thats true, but thats not how to take best advantage of connection caching. > -- > [pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
"jmaimon@ttec.com" <jmaimon@ttec.com> writes:
> Andrzej Adam Filip wrote: >> "jmaimon@ttec.com" <jmaimon@ttec.com> writes: > >> Sendmail by default uses DeliveryMode=backgroud and delivers most >> messages at once *WITHOUT* "processing the queue". > > Yes thats true, but thats not how to take best advantage of connection > caching. AFAIR (from exim "design philosophy") under normal conditions 80%-90% of submitted email messages are assumed to delivered "at once". It is possible to make *today's* sendmail much better "resuse" of outgoing SMTP connections by changing delivery mode to queue and using queue groups selected by recipient address *BUT* as I understand it will hit I/O load (especially on journaling filesystems). Signifficant improvements of outgoing session reuse without significant redesign of andmail and without need to queue are possible but they would require using of "not fully portable features" in sendmail sources. -- [pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl |
|
![]() |
| Outils de la discussion | |
|
|