id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
163	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 [source:foolscap/banana.py#L485 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.
"	task	closed	major	0.8.0	performance	0.5.1	fixed