[Chandler-dev] Chandler sharing TCP and SSL usage

[Lisa Dusseault]

I wanted to take a look at the performance of sharing.  I started  
from "the bottom", looking at TCP and SSL connection characteristics  
before looking at WebDAV usage patterns or performance within either  
the client or server codebase.  Since I had a May 21 version of  
Chandler handy I used it from home, talking to cosmo-demo, and some  
random data (22 events).  I captured the Chandler "Publish"  
interaction only.

The publish took five minutes.  Ekr helped analyze the trace with  
[[http://www.rtfm.com/ssldump/][SSLDump]] (you can use it too, it's  
under BSD license).

The summary is that there are a bunch of TCP/SSL issues to  
investigate on the Chandler side first.
1)  There are 7 separate SSL connections during Publish.  Only 1  
should really be needed.  An ignorant guess is we'd be using  
PyOpenSSL classes in different places, instantiating new and separate  
objects rather than passing one around (or looking one up) to handle  
the sharing traffic.
2)  Even within one SSL connection, traffic is slow.  Between  
establishing the TCP connection and starting the SSL handshake, the  
log shows a 0.5 second delay.  The handshake takes another 0.2  
second.  The actual transaction takes only 0.1 seconds.
3)  There's something weird going on with the connection that starts  
at 9:35:15 in the trace.  After opening the connection, it's two  
minutes before the client sends any data.  This is rather aberrant.
4) The client hung up on one of its own connections, the same one  
where it delays 2 minutes. Why?

More details, raw tcpdump file, tcpdump text output, ssldump text  
output, chandler.log and twisted.log are all attached to the Wiki:  
http://wiki.osafoundation.org/bin/view/Journal/PublishConnectionAnalysis

I hope this is useful to developers, even though the older version of  
Chandler and working from home may make the data a little rough.   
I'll be in the office tomorrow and online today if anybody wants to  
discuss.

Lisa