investigate SSL_write() efficiency

[Brian Warner]

While reading over ​http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html , I learned the following tidbits:

• "OpenSSL will build a record from each call to SSL_write and the kernel, with Nagle disabled, will send out packets to minimise latency"
• "The overhead of a record is typically 25 to 40 bytes"

Foolscap does lots of small writes: every call to sendToken() results in two or three calls to self.transport.write (header, typebyte, body), and multibyte integers are even worse (one write per byte).

I'm not entirely sure about how this ends up translating into calls to SSL_write() (and thus records, with their 25-40byte overhead), but if it's one-to-one, this would be pretty bad.

The task is to examine the output of a packet sniffer (like wireshark, and give it the tub.pem file so it can decrypt the traffic), and could the number of records for a simple message (perhaps a tuple of two ints and two strings).

There's a pretty good chance that twisted.internet.abstract.FileDescriptor.write is involved, which would merge all the write() calls that occur in a single reactor turn (until select() tells us the socket is writable), which would help a lot. On the other hand, the overly-streaming-friendly serialization scheme that Foolscap uses might allow a reactor turn between each call to sendToken, which would hurt a lot.