For July:
connects : 31228
timeouts : 57
too many connects: 28
auth : 165
auth time : 73 msecs
total tls : 0
tls time : 0 msecs < TLS was not enabled
cs time rset : 263.850 secs
cs time quit : 18695.359 secs (5.9 hours of IDLE CPU waste)
data rset time : 24 msecs
data quit time : 1701 msecs
For August:
connects : 25494
timeouts : 90
too many connects: 259
auth : 238
auth time : 78 msecs
total tls : 67
tls time : 698 msecs
cs time rset : 183.326 sec
cs time quit : 25618.925 sec (7.1 hours of IDLE CPU waste)
data rset time : 16 msecs
data quit time : 2283 msecs
Some of the known domains with high CS delays:
Facebook.com 5 secs
moveon.org 5 secs
Google.com 30 secs
hoffman.proper.com 6-12 secs
aol.com 6 secs to 263 secs
qualcomm.com 5 secs
The majority have QUIT delays of less than 1 seconds. The majority of
the CS 1+ delay were 5 secs. Sorting and Eyeballing, it looks like
more of the high ones from 60 to 260 secs are spammers.
The #1 difficulty is its anonymous nature thus all of these clients
are lumped with The Good, The Bad and the Ugly and having trouble why
we are allowing an implementation issue dictate how SMTP is implemented.
Putting aside the negative aspect, it appears to me that the lower the
Delay, the less efficient it is for the CS side. For example,
Facebook with 5 secs delay never had a multi-transaction session. It
assumes the a single or a collection of users with the same host are
generated at at a faster rather than 5 seconds. My wife made an
interesting point that she didn't thin Facebook was sending comments
within 5 seconds. But if that was the case, Faceback is delaying to
build up comments. So I check the looks to look at the time
differences between sessions and they varied but most interesting was
seeing a few concurrent message (same time to the msec) and they were
separate single message sections. Why wouldn't it do a CS here?
On the other hand, there were logs with a few google.com sessions and
its 30 sec delay. I also manually tested it by creating two gmail.com
10 secs apart and once the first session and send the transaction, 10
secs later the 2nd transaction came in.
So disregarding the negatives, it seems higher the better but only
when there is a higher potential to do more work. The last work (1
message) all these 30 secs idle times are pure waste on the receiver.
TLS is highly dependent on the distance or hops between endpoints. I got
0.015 secs across 1000gb LAN - lowest
0.129 secs VPN 17 hops
2.697 secs rejected spammer - highest seen
The 15 ms on the LAN is pretty darn fast for SSL. So for CS clients
working on a private network, TLS time should be insignificant
overhead. The VPN speed was pretty good tool, given the fact that its
a 1/2 mile distance yet it traveled across two states (Up Florida,
into Atlanta Georgia and back down). The highest was 2.7 secs but the
average was 0.6 secs among all the other clients.
I question the need for TLS for CS clients especially when they are
not sending multi-messages.
No CS client can do AUTH on our server, so the above times is internal
users and thats pretty fast at 78ms
Anyway, it appears to me that even if one deems CS beneficial, they
are certainly implementing it in an efficient for themselves or for
us. 7 hours of idle lost time with no work is pretty wasteful - on
both ends.
--
Sincerely
Hector Santos
http://www.santronics.com