我的问题是关于Linux上的Python套接字编程，但由于Python的socket模块只是系统调用的包装器（recv，recvfrom等），所以它并不强烈蟒。
因此，根据docs，当我们调用recv方法时，
为了最好地匹配硬件和网络现实，bufsize的值应该是2的相对较小的幂，例如，4096
这是什么意思？
与硬件和网络现实最佳匹配
我最关心的是表现。
如果我通过我的自定义缓冲区（我后来在我的代码中用作数据容器，它只是一个 memoryview ，如果它很重要），它会成为我的网络软件的瓶颈吗？ em> not-power-of-two 自定义大小到socket.recv_into方法？
它只是一行代码，清晰而简短。
但我的缓冲区大小可以是17或51或者其他什么，所以我想知道，我应该实现一些内部环状缓冲区，具有“好”大小（如4096）并使用它来从套接字读取数据在具有如此“好”大小的块中并将其写入那里，然后复制到我的缓冲区？
在性能方面有任何意义吗？
或者我当前的方案（当我从一个插件中读取数据时，“坏”大小，与“2的幂”规则不匹配）是不是很好？
换句话说：如果我们从1023大小而不是1024的块中读取套接字，它会影响性能吗？
答案 0 :(得分：6)
为了最好地匹配硬件和网络现实，价值 bufsize应该是2的相对较小的幂，例如，4096
您应该考虑以太网数据包的最大大小（~1500字节）和TCP数据包的最大大小（~64K）。你真的想要一个大于第一个的缓冲区（所以1024，可能是不可能的）你可能不需要比后者更多。所以选择2K，4K，8K，16K，32K或64K。
他们也暗示内核使用大小为2的缓冲区（由于TCP最大数据包大小可能是64K），你需要付出努力并匹配它，所以不会有小/中等大小阅读时剩下的（modulu你的数据包大小）。
示例：假设您使用的是1023字节缓冲区，并且由于正在发送大量数据，因此TCP数据包的最大值为64K。你将有64个1023字节的迭代和64字节的浪费额外迭代。