Re[2]: [Declude.JunkMail] OT: MaxDSNSize

[Sanford Whiteman]

 [...\Services\InetInfo\Parameters\ThreadTimeout]   seemed   to  make
 sense,  though I'm not sure that it solves anything and I'm not sure
 if it has any consequences yet.

This tweak would apparently hinder, rather than help, the issues under
consideration.  This  setting  allows  already-allocated threads to be
completely stopped, rather than simply idling while waiting for input.
If  your  system  is  periodically going up to a peak number of active
theads,  stopping  them completely during idle periods just means they
have  to  be  created  again  during  peak periods. The cycles used to
create  and destroy the threads are unnecessary overhead. Doesn't save
anything  overall,  as  a  system that can handle n active threads can
obviously  handle n idle threads! The only extenuating situation is if
you  have _other_ applications whose peak thread allocations are known
to occur at different times.

--Sandy

---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.

Re[2]: [Declude.JunkMail] OT: MaxDSNSize

[Sanford Whiteman]

 I  have not yet tested out any changes to the threads. It seems that
 people don't want to discuss it.

Oh,  I'll discuss it. . . but I don't really don't know why the burden
of  proof  fell  my  way,  rather  than  this stuff being investigated
_before_ declaring without real testing that MS SMTP isn't scaleable.

With the following entries:

ListenBackLog 200

MaxConcurrency 200

MaxPoolThreads 200

PoolThreadLimit 256

AdditionalPoolThreadsPerProc 100

I  am able to have open up to 137 receive threads on an Athlon 64, 512
MB RAM, 2 x 7200 RPM SATA RAID. It's clear that the claimed bottleneck
doesn't exist when a system is properly tweaked.

People  testing  this  further must be aware that IIS SMTP dynamically
balances  connections  between  I/O completion ports alone (which have
less  overhead than threads, but which cause thread starvation if used
exclusively),  and  full-fledged  threads together with I/O completion
ports.  This  dynamic  adjustment  is  why  you  should  not expect an
arithmetic  relationship  between  the  number  of connections and the
number  of  threads. It can be difficult in a low-end laboratory setup
the  long-lived connections necessary to force the uptick in allocated
threads.  You  may  think  you're  testing properly, but the server is
actually closing and opening the connections in pace with the clients,
so  it never has a need to allocate more threads. But when the need is
there,   and  the  Registry  maximum  thresholds  have  been  properly
extended, the threads will be made available.

I'm  not  bothering  to  test  the  IIS  FTP  service  vis-a-vis  this
information,  since  I don't use that service. My mission was to prove
that  MS  SMTP  can flexibly expand its thread pool beyond the default
limit to account for long-lived connections. Q. E. D.

--Sandy



Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]

SpamAssassin plugs into Declude!
  http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/

Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases!
  
http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/
  
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/

---
[This E-mail was scanned for viruses by Declude EVA www.declude.com]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.