Alessandro Vesely wrote:
On 20.08.2011 08:38, Hector Santos wrote:
Well, It (Connection Sharing) is still a poor one-side only benefit logic and
probably this fact was realized long along and simply not employed in any
significant way and if it is, probably isolated to specific host and for the
rest, if employed, has a very short (perhaps 5 secs) hold time.
SMTP offers the option to shove several transactions into a single session,
thereby re-using costly TCP and TLS handshaking for multiple messages. How
can a server take advantage of that option?
One possibility is to sort queued messages by MX, but this implies a delay
and is error-prone. Another possibility is to sort recipients by
domain-part, which can be done by the submitter.
For example, a mass mailer script that produces personalized messages for
each recipient can simply hand them to the MSA in the right order. The
number of seconds that a connection remains dormant needs just be enough for
the next message to be generated and submitted.
Agree, but only from the design perspective of one side to make it
work at the expense of presuming there is a unlimited number servers
and there are no other clients doing the same thing and the server
capacity is rarely reached so that server availability is not impacted
and the server cost to maintain steady state performance is minimal.
Its a selfish idea from the standpoint that it considers its own
benefits by ignoring the impact at the receiver. But I do think its a
useful method if its prearrange with the receiver in the same way we
white list specific senders (i.e, Allow Relay IP tables, smart
hosting, etc).
This can be easily modeled and simulated using this formula:
C = R /(S+H)
where
R = Total number of available receivers
S = Average Session Time
H = Average Holding Time (CS cache wait time), and
C = Arrival rate of new clients
Example #1 - No CS consideration H=0
R = 100 receivers
S = 5 secs
H = 0 secs
Then for the maximum efficient, high production steady state condition:
C = 100/(5+0) or 20 CPS (clients per sec)
This means that all 100 receivers are busy 100% at all times. It is
steady state when C does not increase.
Example #2: CS considered, H=5
Now add the artificial CS Holding Time, H=5, assuming the maximum hold
time allowed by SMTP is 5 mins idle time, and you have:
C = 100/(5+5*60) or 100/305 or 0.3 CPS or 1 client every 3 seconds!
So without changing total receivers or impacting the service time, the
client arrival rate decreases.
If we want to maintain a 20 CPS, something has to change, like R or S
and that is my basic point that CS only benefits the client and can
potentially have a high impact on the receiver by forcing new loading
requirements and service availability design issues.
Of course, there are all kinds of other considerations but the above
shows where your bottlenecks can occur.
I think all agrees that H has to be very small so that the receiver is
not impacted in any significant way. The SMTP "Pressure Relief" (i.e.
221 and Retry strategies) recommendations will help move it or keep it
stable.
--
Sincerely
Hector Santos
http://www.santronics.com