4

My question is about sockets programming in Python on Linux, but since Python's socket module is just a wrapper over system calls (recv, recvfrom etc.), it's not strongly about Python.

So, according to docs, when we call a recv method,

For best match with hardware and network realities, the value of bufsize should be a relatively small power of 2, for example, 4096

What does it mean?

best match with hardware and network realities

Mostly I care about the performance.

Will it be a bottleneck in my network software, if I pass my custom buffer (that I use as a data container later in my code, it's just a memoryview if it matters) with some not-power-of-two custom size to socket.recv_into method?

It'll be just one line of code, clear and short.

But my buffer's size can be 17 or 51 or whatever, so I'm wondering, should I implement some internal ring-like buffer with a "good" size (like 4096) and use it to read the data from a socket in chunks with such a "good" size and write it there, and then copy to my buffer?

Does it have any sense in terms of performance?

Or my current scheme (when I read the data from a socket in chunks with a "bad" size, that doesn't match "power of 2" rule) is fine?

In other words: will it affect the performance, if we read from sockets in chunks with 1023 size, rather than 1024?

d-d
  • 1,775
  • 3
  • 20
  • 29
  • 1
    If that really bugs you, you can always create a [BufferedReader](https://docs.python.org/3/library/io.html#io.BufferedReader) on top of your socket. It will ensure reads are done in reasonable chunks, while letting you read the amounts you like. – spectras Nov 06 '16 at 11:48
  • Also see [this question](https://stackoverflow.com/questions/6363523/what-is-the-actual-impact-of-calling-socket-recv-with-a-bufsize-that-is-not-a-po) for a full history, including who wrote those words. :) – Russ Aug 26 '19 at 22:37

1 Answers1

9

For best match with hardware and network realities, the value of bufsize should be a relatively small power of 2, for example, 4096

You should consider the max size of Ethernet packets (~1500 bytes) and the max size of TCP packets (~64K). You really want a buffer larger than the first (so 1024, is probably out of the question) and you probably don't need more than the latter. so go with 2K, 4K, 8K, 16K, 32K, or 64K.

They are also hinting that the kernel uses buffers with a size of powers of 2 (probably 64K due to TCP max packet size), you want to take the effort and match it so there won't be a small/medium sized leftover (modulu your packet size) when reading.

Example: Let's say you are using a 1023 byte buffer, and since a lot of data is being sent, then the TCP packet is maxed out at 64K. You'll have 64 iterations of 1023 bytes and a wasteful extra iteration of 64 bytes.

Shloim
  • 5,281
  • 21
  • 36
  • 5
    Also, there is an extra cost of making 64 system calls for 1kb instead of 1 system call of 64kb. System calls involve changing a lot of internal processor state, that takes time. That's why we do buffering: doing the 1 system call and dividing in chunks in user space avoids the system call overhead. – spectras Nov 06 '16 at 12:06