用于读取文件然后发送数据包的适当缓冲区大小
我有一个小型 Web 服务器应用程序，它从文件流中读取 X 个字节，然后将这些字节输出到打开的 TCP 流。
我稍微尝试了一下，例如，将缓冲区大小设置为 1024，然后将其提高到 5120，并没有看到太大的改进。我还尝试将其大小设置为 1，但我发现速度大幅下降。
我知道我会受到介质的读取速度以及网络的限制，所以我很好奇如何设置这个数字。我可以将其设置为在所有情况下都最佳的某个数字吗？
I have a little web server application which reads X bytes from a file stream then outputs those bytes to an open TCP stream.
I played around with it a little bit and, for example, having a buffer size of 1024 then bumping it up 5120 didn't see much improvement. I also tried making it with a size of 1, to which I saw a huge speed decrease.
I know I'm going to be limited by the read speed of the medium, and also by the network, so I'm curious about how to set this number. Is there a certain number I can set this to which will be optimal in all situations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，因为这取决于您提到的因素，以及 I/O 库和操作系统中的缓冲。不过，使用磁盘块大小、内存页面大小和/或网络数据包大小（不要忘记协议标头！）的倍数的某个值通常是明智之举。
如果速度很重要，那么如果可以避免的话，根本不要通过内存复制块。例如，Linux 有
sendfile为此进行系统调用。No, because it depends on the factors you mentioned, as well as on the buffering in your I/O library and in the operating system. Using some value that is a multiple of the disk block size, memory page size, and/or network packet size (don't forget the protocol headers!) is generally a wise move, though.
If speed is essential, then don't copy the blocks though memory at all if you can avoid it. Linux, for example, has the
sendfilesystem call for this.没有一个确定的数字。但是，使用不同的缓冲区尺寸运行大量测试，也许使用网络模拟工具来模拟不同的网络条件，可以对选择不同的合适的缓冲区尺寸有很大帮助。我在优化 VoIP 客户端时就是这样玩的，它对我帮助很大。
There isn't a certain number. But running a lot of test with different buffer dimension and perhaps using a network simulation tool to simulate different network conditions, could help a lot in selecting different suitable buffer dimension. I played this way while optimizing a VoIP client and it helped me a lot.
更重要的因素是套接字发送缓冲区大小。将其设置为至少 32k。
The more important factor is the socket send buffer size. Set this to at least 32k.