使用 Boost.Beast WebSocket 时测量客户端备份答案

【问题标题】：Measuring client back-up when using Boost.Beast WebSocket使用 Boost.Beast WebSocket 时测量客户端备份
【发布时间】：2020-05-24 14:51:14
【问题描述】：

我正在阅读 Boost.Beast WebSocket。当我的应用程序得到备份时，websocket 发送方似乎很乐意延迟/缓冲数据（大概在应用程序级别，因为它们会延迟 1 分钟或更长时间）。

如果我得到备份，最好的衡量方法是什么？例如，我可以查看 TCP 缓冲区的大小吗？我还可以在快速线程中将所有数据读入内存，并将其放入慢速线程的队列中（在这种情况下，备份可以通过队列的大小来衡量）。但是我想知道是否有更直接的方法。

【问题讨论】：

您似乎确切地知道“备份”是什么意思。我不认为这是常见的行话。你能用语言表达你所看到的，以及你认为正在发生的事情吗？我认为一般来说，队列机制 /（可选地带有 / 协议反馈功能，例如“发送更少的请求”，甚至“这种 [类型] 请求将在 n 毫秒内被接受”）是处理服务器过载的正确方法。如果您认为延迟发生是因为 IO 线程被非 IO 拖慢了，您可以将它们分开
“备份”是指“排队”——我处理数据的速度比接收数据的速度要慢。排队发生在我的应用程序级别以下 - 在入站 TCP 缓冲区中。我试图找出一种方法来了解这一点。一种方法是boost::asio::basic_stream_socket<boost::asio::ip::tcp>::available()，但该函数需要大约 3us 才能运行，这比我希望的要慢。我没有能力告诉发件人在应用程序级别放慢速度。当我的 TCP 缓冲区已满时，它们似乎会变慢，但我不确定为什么 - 可能是丢包/重新传输？

【解决方案1】：

这因平台而异，但有 SO_RCVBUF 选项设置在 TCP 暂停接收更多数据之前可以排队到套接字上的数据量。

如果您有权访问套接字 s，请调用它来检查其 rcv 缓冲区大小可以容纳多少数据

    net::socket_base::receive_buffer_size opt = {};
    s.get_option(opt);

您可能会看到它默认为 64K 左右。

然后把它调高到像一个兆字节：

    net::socket_base::receive_buffer_size optSet(1000000);
    boost::system::error_code ec;
    s.set_option(optSet, ec);

YMMV 关于您可以传递给 set_option 调用的值有多大以及实际有多大帮助。

请记住，这只是缓解压力的临时措施。如果你不断得到备份，你只会再次达到极限，只是稍晚一点，也许不那么频繁。

我还可以在快线程中将所有数据读入内存，然后将其放入慢线程队列中

是的，但是您基本上已经完全实现了 SO_RCVFROM 的功能。要么是这样，要么你在内存成本方面缓冲到无穷大（没有限制）。

【讨论】：