Jacob-Burckhardt
commented
2 years ago Give library time to write.
https://docs.websocketpp.org/md_tutorials_utility_client_utility_client.html says:
In the case of applications that call send from inside a handler this means that no messages will be written to the socket until that handler returns.
Therefore make sure your handler returns quickly.
When I saw a problem similar to yours, I used google pprof (https://gperftools.github.io/gperftools/cpuprofile.html) to determine if lots of CPU time was being used in my handler since if lots were used then that means I was taking CPU time away from the library preventing it from sending out messages. If however, you see lots of CPU time in the library it might mean there are so many messages that it does not have enough CPU time to send them.
Is the client reading too slowly?
https://github.com/zaphoyd/websocketpp/issues/683 says:
If your trouble is that you are sending too quickly for the network connection to deliver, the get_buffered_amount() method can help you determine when to back off.
I thought maybe my clients were reading too slowly causing the websocketpp server to not flush messages from the buffer to the socket. But I ruled out that theory by using Wireshark to show that the client TCP window sizes were always more than 19,968 bytes when get_buffered_amount is high. But, maybe your clients are reading too slowly, so you might want to check the window size.
This has more suggestions: https://github.com/zaphoyd/websocketpp/issues/1005#issuecomment-887891891
I used websocketpp to send image data to web, but the buffer of websocket server kept getting larger until the server crashed. How can I handle this?