cvoica
commented
1 year ago I debugged the application and noticed that the _rxbuf is big when the rates start to drop.
The _rxbuf.erase(_rxbuf.begin(), _rxbuf.begin() + ws.header_size + (size_t) ws.N); is then slowing down the application.
(gdb) print _rxbuf.size()
$2 = 40256441
(gdb) python
>import time
>s=time.time()
>gdb.execute("continue 3000")
>print(time.time()-s)
>
Breakpoint 1, ix::WebSocketTransport::dispatch(ix::WebSocketTransport::PollResult, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, bool, ix::WebSocketTransport::MessageKind)> const&) (this=this@entry=0x7ffc62228fb8, pollResult=<optimized out>, onMessageCallback=...) at /home/root/IXWebSocket-11.4.3/ixwebsocket/IXWebSocketTransport.cpp:550
550 emitMessage(_fragmentedMessageKind,
7.368263244628906
(gdb) print _rxbuf.size()
$3 = 38810270
(gdb) where
#0 ix::WebSocketTransport::dispatch(ix::WebSocketTransport::PollResult, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, bool, ix::WebSocketTransport::MessageKind)> const&) (this=this@entry=0x7ffc62228fb8, pollResult=<optimized out>, onMessageCallback=...)
at /home/root/IXWebSocket-11.4.3/ixwebsocket/IXWebSocketTransport.cpp:550
#1 0x0000559f77ce1e89 in ix::WebSocket::run (this=this@entry=0x7ffc62228fb8) at /home/root/IXWebSocket-11.4.3/ixwebsocket/IXWebSocket.cpp:382
#2 0x0000559f77c92847 in WebInterface::run (this=this@entry=0x7ffc62228fa0) at cpp/src/client/webinterface.cpp:91
#3 0x0000559f77c8e5e5 in main (argc=<optimized out>, argv=<optimized out>) at cpp/src/client/main.cpp:20
While using the library I observe the below behavior: the client application, which is only counting the messages and displays the below output every second, is able to receive messages at a high rate for several seconds. This period is sometimes longer than a few seconds seen below. Then the rate drops by a lot, couple of hundreds KB/s.
In the server I have a timeout and I disconnect a blocked reader after 20s. The disconnection from the server side occurs in at 15:19:43. As you can see below the client keeps displaying that it gets message. This means that it reads from memory which I did investigated and got to suspect the handling you have on the _chunks list.
I was then thinking that it might benefit me and your time to look into this together.