Opened 7 years ago

Last modified 6 years ago

#4089 enhancement new

Add a performance tuning API for intelligently initializing, inspecting, and tuning send/recv buffer sizes

Reported by: Glyph Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: itamarst Branch:


Twisted currently has two public-but-not-really attributes, twisted.internet.abstract.FileDescriptor.SEND_LIMIT (set by default to 131072) and twisted.internet.abstract.FileDescriptor.bufferSize (set by default to 65536). There are a couple of problems with the way this is done:

  1. the attributes, despite having public names, are not present on an interface such as ITransport, so they are not really exposed for tuning. I suggest that we add a tuning API at 3 layers. These tuning APIs should set SO_SNDBUF and SO_RCVBUF socket options such that they will match these values, and the kernel will work to get us data of the appropriate size. (Maybe there is a case where someone would want these values to be different from the kernel's idea? If so that should also be available in each of these APIs.)
    1. at the reactor level, to set the defaults for every connection (which is what you want to do 90% of the time)
    2. as an argument to listenTCP and connectTCP, to set defaults for all connections coming from that accept() or connect() call (although maybe this should be on IConnector and IListeningPort instead, since adding a method to those objects is easier than modifying a signature)
    3. as a method on the transport itself.
  2. The current APIs are undocumented (as they are left over from pre-documentation-standard days.
  3. The current initial values are completely arbitrary. We do need some numbers here (in particular, we have to pass some number to recv(), especially) but reasonable values can be derived from getsockopt via the SO_SNDBUF and SO_RCVBUF defaults.
  4. The current naming is inconsistent and confusing. One is named as if it's a constant (it isn't, really) and one is named as an instance variable; the 'send' one indicates its role in its name, but the 'recv' one sounds more general.

Change History (5)

comment:1 Changed 7 years ago by Glyph

I am also told that sometimes the operating system will be doing something smart with these values, such as setting them based on the route or interface that a socket is talking to. So the default should be to initialize the values *after* completing or accepting a connection, in case we've gotten some hints from the OS about how big our send/recv buffers should actually be.

comment:2 Changed 6 years ago by <automation>

Owner: Glyph deleted

comment:3 Changed 6 years ago by Itamar Turner-Trauring

Cc: itamarst added

As noted in #5094, sockets will sometimes accept *more* bytes than SO_SNDBUF.

comment:4 in reply to:  3 Changed 6 years ago by Glyph

Replying to itamar:

As noted in #5094, sockets will sometimes accept *more* bytes than SO_SNDBUF.

Can you attach the test program that you used to verify this so that we can run it on multiple platforms and collect some experimental output?

comment:5 Changed 6 years ago by Jean-Paul Calderone

As noted in #5094, sockets will sometimes accept *more* bytes than SO_SNDBUF.

It should accept about SO_SNDBUF + remaining TCP window.

Note: See TracTickets for help on using tickets.