Dashboard very slow

I am using Node-RED to monitor a process, but I am in a point that it is not usable because the dashboard has a very slow response.

Hay checked the flow by debugging (I put debug nodes together with the dashboard nodes) and the flow works properly, with any apreciable delay. But the dashboards has a extremely long delay (about 20 seconds or more) if it doesn't lose connection during some seconds.

What can be the reason of such a long delay and instability of the dashboard?

Node-RED is running in a PC, and all the communications are wired:

  • A Serial node for reading a weighting scale, which sends some 10 frames per second (each frame has 14 bytes).
  • A serial node for reading another instrument, which sends a frame when requested. I am requesting 4 frames per second.
  • A ModbusTCP node for reading 2 registers from an Arduino that is connected point to point with an ethernet cable. I set a poll rate of 2 registers per second, but it would be desirable more registers.

There is not a lot of computation with the gathered data. I Just extract the variables from the ascii frames received from both serial nodes, change units, and some basic arithmetic operations, and insert the desired variables into object properties. The only thing are SQL requests for inserting the output values into a DB through an SQLite node.

As I mentioned before, the debug nodes show that there isn't any appreciable delay, but something is collapsing the dashboard.
The dashboard has the following elements:

  • 6 text elements showing numeric values.
  • 2 analog gauges
  • One switch to activate/deactivate the DB insert requests.
  • Two time charts showing the evolution of 3 values (two of them are shown in the same chart)

The switch also shows the long delay, since it doesn`t respond when clicked (it responds quite a long time later, if it does).

Do you have any idea?
Some one commented in other threads that charts slows down the dashboard. Is it so? Should I avoid using the charts?
Would the response time and stability of the dashboard be improved if I reduce the rate that the chart shows the values?
I would maintain the flow-rate because I need to register values with a good time-resolution for post-processing, but the realtime display would be more coarse...

Thanks in advance and best regards,

If you restart node-red (or otherwise clear the charts) does it start off ok and then slow down as you add more points to the chart? If so then you may be overloading the browser handling a large number of points.

Are you adding points to the chart multiple times/second and what time range are you showing on the chart?

Are you running the browser on a low power machine such as a Pi 3? If so then if you run the browser (not node-red) on a PC instead is it better?

1 Like

Thanks for your reply,
I am running Node-Red (and the browser) in a fanless PC whose processor is a intel i5 with 8 GB RAM, and the PC isn't running any other relevant software at the same time.

I reduced the number of points per second that are sent to the chart and it improved. At the beginning one of the charts was showing one point per second and the other chart showed 2 points per second. Now the first one shows one point each 5 seconds, and the second chart shows one point per second.
It improved quite a lot, but it isn't as "fluent" as I would like.
are there noticeable differences between using Chrome, Edge or any other explorer?

how many points are you displaying ? over what time period etc - most charts are only 200-300 pixels wide...

1 Like

I have a lot of data points on my graphs and I note from learning how to put a dashboard together there are a lot of things that can make it go slow.

Possible causes of slowness:

It's important to have enough spare CPU so everything renders quickly. You can add a CPU monitoring node to see if is too high, even alert yourself. For normal operation you should never have a period of 90% CPU for more than 10 times a minute. If you do, one of your flows is misbehaving. 90% CPU all the time means you have lots of waiting and flows might not run in a timely manner.
The best way to find the culprit node is to start disabling flows until CPU goes down again.

Recursive Loops in the Dashboard
I had a dashboard flow that allowed a button to be clicked which then changed the text displayed on the button. If you have the button status of "pass through" then sometimes it would be an infinite loop which kills CPU.

Other things running on the machine
I had InfluxDB and Grafana running on the same Raspberry Pi 3B. Due to CPU issues I had to switch off debug logging to bring CPU down to < 50%.

No spare CPU on the machine the dashboard is being displayed on
If you are in a video conference on the machine the dashboard is being shown on, sometimes the browser won't render in time and the dashboard times out. "Connection Lost" errors.

More than 1000 data points in your graphs
I persist the graph data every five minutes so if Node Red is rebooted you can get all your data back and not start from scratch. But this takes a little CPU because the messages being passed out of your graph node to your persisting node can have up to 1000 entries in a huge array. I had the maximum data points in my graph set at 10,000 originally and reduced it to 1000 when I noticed things were becoming sluggish.

A PC shouldn't have any trouble with speed compared to a Pi, and I have 7 very full tabs of nodes.
Calculations don't seem to have much impact either on CPU.

You can see the graphs in this picture below:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.