ietf-smtp
[Top] [All Lists]

FWIW Connection Sharing Stats

2011-08-26 15:04:36

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


<Prev in Thread] Current Thread [Next in Thread>