当使用套接字时，选择比所需更大（或更小）的缓冲大小有什么好处和缺点？
以我的具体案例为例，我正在使用Python中的UNIX流套接字为我正在开发的应用程序实现基本的IPC。有一个“服务器”进程和许多“客户端”进程。客户端进程连接到服务器进程的套接字并向其发送命令。服务器进程接收这些命令并执行它们。它们使用的协议非常简单，唯一值得注意的规则是每个命令必须以一个后缀结尾。
客户端可以在每条消息中发送任意多或任意少的命令（甚至是部分命令，其中命令的其余部分和伴随的命令包含在将来的消息中）。服务器处理并将消息存储在队列中，直到它收到一个命令，然后将完成的命令保存到队列中。
描述我的简单示例的目的是为了说明在信息传输方面，传递给socket.recv（）的buffsize参数是完全无关紧要的。即，我可以调用socket.recv（1）或socket.recv（1024），程序的行为不会改变。
在这种情况下，buffsize在底层应用程序的整体执行中没有任何作用，选择此值的好方法是什么？在做出此决定时需要考虑哪些重要事项？
1条答案
按热度按时间a11xaf1n1#
假设您询问的是传递给每个
recv()调用的字节计数参数（而不是与套接字关联的内核内部接收缓冲区的大小，并且可以通过setsockopt(SO_RCVBUF)进行更改），那么这在很大程度上是一个品味问题。向
recv()传递更大的值的好处是，您可以一次接收更多字节的数据，因此您可能需要调用recv()更少的次数来收集相同数量的数据。这可以通过减少数据传输的每字节开销来提高CPU效率。向
recv()传递一个较小的值的好处是，您可以减少recv()调用所需的最坏情况下的RAM量，因为该参数限制了recv()可能需要在单个数组中返回的存储字节数。现代计算机有足够强大的CPU和足够的RAM，在大多数情况下，你选择的值不太可能产生可测量的差异。在剩下的少数情况下，最大化性能 * 是 * 重要的，选择更大的recv-size可能会执行得更好，尽管传递比socket的
SO_RCVBUF缓冲区的大小更大的size-value不太可能产生任何差异，因为无论如何，内核一次不能给你比它能存储的更多的字节。