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	new	major	undecided	performance	0.5.1