-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: Connecting to a very high traffic websocket server stalls #1873
Comments
Thank you for opening the issue. We will try to resolve it as soon as possible. |
Hey, I'd love to contribute to this issue. Is it still available? |
@KaviiSuri You can take this on if you want! Assigning to you! |
Thanks @AndrewBastin! I'll need some guidance as I'm new to opensouce. I was thinking of solving this by rate limiting the number of messages received (we could make the limits configurable from UI) Sort of how this library implements it (appears to be for the backend though) The gist of it is:
|
Maybe as a first step, but why not just handle the load gracefully? The rislive website can do it, with no filtering at all (host = null), i get a ~20 mbit/s flow of messages, and it works fine. Wireshark can capture all packets my computer is sending/receiving and is only limited by available memory on my computer. |
I'll look into their website on how they do it. Do you have any ideas on what the bottleneck might be for us? It might be the rerenders due to state update, will experiment a bit |
@KaviiSuri feel free to ask for help, you can also DM me directly on Discord if you want any help or have questions about the codebase and how stuff work (you can find me in the Hoppscotch Discord Server). @Gunni As for the approach, I actually gave a crack at this issue long back (the branch is really stale now), the main bottleneck with the rapid firing sources on Hoppscotch turns out isn't the memory issues, but more related to how Vue functions and how much time Vue spends on diffing the Log component. The RIS Live site you mentioned also doesn't render all the entries below (as mentioned by its disclaimer) and instead just renders a static number of them.
A solution could be to virtualize the log component list so the only viewable logs get rendered (fixes diffing time to a constant value) along with small practices like buffering and stuff. We can still track render times (ticks) and see if we are lagging behind and then drop messages if so. Internally though, we already have plans to rework the Realtime pages a bit and add some more features and some optimizations. You can still work on this if you want in case we couldn't fix it on our internal cycle. |
Hello @AndrewBastin, I would like to take over this issue if it is not in progress now. |
Hi @ashiishme, @KaviiSuri reached out to me a while back saying he is working on this. @KaviiSuri please confirm you are working on it |
Yeah I'm working on this, will send a PR soon |
Is this still up for grabs ? @KaviiSuri @AndrewBastin |
@ganudoomer yes you can pick this up if you want. |
Hey @AndrewBastin, would like to work on it |
@Gunni, have found the issue, let me know if it is still open to work |
afaik nobody has solved this, but it's been a long time. |
Hi, I was planning to update the regex to allow that particular syntax of wss urls function generateREForProtocol(protocol) {
return [
new RegExp(
`${protocol}(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(:[0-9]+)?(\\/[^?#]*)?(\\?[^#]*)?(#.*)?$`
),
new RegExp(
`${protocol}(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]).)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9-]*[A-Za-z0-9/])(:[0-9]+)?(\\/[^?#]*)?(\\?[^#]*)?(#.*)?$`
),
]
} Please Guide me on how I can replicate this issue? |
Thanks for fixing the parsing! I am unable to reproduce the freezing issue too! Good? |
Great, Then I ll create a PR for the parsing? |
is this issue resolved? I am new to open source and have also been working on MEVN stack if you can suggest me how to get started it will be of great help to me. |
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
wss://ris-live.ripe.net/v1/ws/?client=hoppscotch.io
{ "type": "ris_subscribe" }
to the remote serverExpected behavior
ris-live is a stream of bgp announcements on the internet, with the
{ "type": "ris_subscribe" }
we don't filter it at all, there are over a thousand messages per second.Screenshots
Stalls at this point
Desktop (please complete the following information):
Additional context
Parameters on wss urls is considered invalid, but f.ex ris-live requires it.
The text was updated successfully, but these errors were encountered: