Opened 14 years ago
Closed 10 years ago
#163 closed task (fixed)
investigate SSL_write() efficiency
Reported by: | Brian Warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.8.0 |
Component: | performance | Version: | 0.5.1 |
Keywords: | Cc: |
Description (last modified by )
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.
Change History (2)
comment:1 Changed 10 years ago by
Description: | modified (diff) |
---|---|
Milestone: | undecided → 0.8.0 |
comment:2 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I looked briefly at a wireshark trace, using the doc/listings/pb2server.py
example. The request caused a 2350-byte message, followed by a 56-byte ACK. The response caused a 796-byte message, followed by its own 56-byte ACK.
So Banana's small writes are being merged, great. This ticket can be closed.
It's a bit odd that a simple callRemote("add",a=1,b=2)
took 2350 bytes to serialize, so that's worth learning more about (specifically how many plaintext bytes were sent). I don't believe TLS is going to expand things by very much (maybe a few bytes of record type, and 16 bytes of MAC).
dragging some old tickets into the next release, kind of at random