Polling shouldn't be a problem, if you look a one line lower down the list there is a websocket version that is connected.
Agreed. But, there was 10+sec worth of polling before the WS established.
the first took a few hundred ms, the highlighted one took 10+ secs to return, then the WS was established.
Ahhhh. So all these errors are from an issue with the websocket?
This is normal?
They are not errors, just normal system handshakes?
It seems that Caddy proxies websockets out of the box.
Some Google results are saying that you only need to tweak the config file if the websockets are on a different port: How to correctly setup Caddy proxy to work with websocket? · Issue #363 · mattermost/mattermost-docker · GitHub
EDIT: Caddy auto setup confirmed here: Caddy Websocket Configuration - Technical assistance - Zammad - Community
Does Node-RED dash2 use a different port for websocket data?
That depends how you have configured things. By default, node-red runs on 1880. web typically on 80 (or 443)
So that might be a contributing factor
there are lots of reasons for the timeouts:
- Network Latency or Unstable Connection
- Misconfigured
pingTimeoutandpingInterval - Server Overload or High CPU Usage
- Proxies, Firewalls, or Load Balancers
- Client-Side Disconnects
- WebSocket Version Mismatch or Bugs
- Mobile and Battery Saving Modes
Take your pick.
No 4 ties up with the default port thing you mentioned.
No 2 is something we might need to look at
No 5, 6 and 7 are really out of your control so can be mostly dismissed for now
Not a different port to Node-RED itself.
I've been wondering if there is a nodejs (or something similar in my control) setting somewhere I've missed form the default Node-RED install.
Where do I find the pingTimeout and pingInterval settings?
Certainly getting a lot of ping timeouts. Though that is usually due to heavy traffic I think.
Having looked more closely at the site, I can see that it does carry a MASSIVE amount of live data and some of the messages are quite large - like 25k
I think with that amount of live data, when you hit some critical number of users, it is simply hitting throughput issues. And once the backlog starts to build, you get a cascade effect that rapidly multiplies the issue.
The best approach is almost certainly - assuming you want to continue using D2 - to split into Multiple Node-RED instances so that you can split the data displays between multiple dashboards.
Unless, that is, someone can think of a way to stop D2 sending data for all "pages" all the time for every connected client.
Is there a way to stop Node-RED sending messages for content that isn't actually visible/active for a connected client?
Any tips on how I find those?
I just now looked at Firefox and Chrome web tools to try and match your screenshot and cant find it.
I'd love to know what ones are the big messages and see if I can do anything about them.
select the WS in the network list, then look at messages tab
You might need to refresh the page while devtools is open
Go to the network tab, you may need to reload the page. Then look for the entry with the code 101 and click on it, then go to the messages tab.
You will see that the client continuously receives messages for "pages" that are not actually active.
I put the word pages into quotes because D2 is actually a single-page app and its apparent pages are not, they are loaded/unloaded Vue components.
I think those massive messages are related to the page with the maps and fly traffic on them. Still can't say if the data contains only necessary stuff. You need to figure out that by yourself.
At least one of the ones I looked at seems to contain a complete dataset for a specific aircraft.
I found the 101 in FF and Chrome, but cant see the messages tab?
Firefox
Chrome
Why do my 101 area (after reload) show zero bytes, but you have a lot more?
That's because of how websockets works - that overview line doesn't show you much. Let me fire up firefox to find the right data there.
The messages are shown on the Response tab in firefox.
Ok I see a zillion messages scrolling now.
No way to tell the size, so its impossible for me to figure if I can reduce the size of any of them.
I cant even tell where any of them are coming from in the code, they all look like family walking past me, they all belong and I know each of them from the first few characters, but hard to say much more at the speed they are scrolling up the page.
Interesting I see the socket IDs
I guess these are the ones I am seeing timeout in the PM2 log. Thats starting to join the dots a bit for me now.
@TotallyInformation Where did you get this from?
This seems a LOT more useful in tracking down the bigger message sources.
Chrome - as per @hotNipi screenshots
