High CPU Usage When Viewing “Edit Device Tags” Page when working with many tags

[eduardoexact]

I found the following bug when handling large number of tags. I observed that the problem just appear when the user open the "Edit Device Tags". It seems that fuxa is pulling all the values even when just a few are beign displayed (10, 25 or 100 depending on the pagination). Solving this can help to handle a large number of tags.

Describe the bug
When the “Edit Device Tags” page is opened and a large number of tags (e.g., hundreds or thousands) are loaded, the CPU usage spikes significantly. This appears to be caused by the application requesting and processing all device tags at once, resulting in a high load on the server.

To Reproduce

Go to the application’s “Devices” section.
Click on the “Edit Device Tags” icon for a device that contains many tags.
Observe that the UI attempts to load the entire list of tags in one go.
Notice a substantial increase in CPU usage on the server or in the Node.js process.

Expected behavior

Only the tags the user needs to see (e.g., a page of 25 items) should be requested and displayed at a time, preventing excessive CPU consumption. Scrolling or paginating should fetch subsequent portions of the tag list without taxing the system.

What I think might be happening:

When users open the “Edit Device Tags” page, the frontend requests all MQTT tags at once. This leads to high CPU usage on the server (Node.js) because:

1. The server fetches and processes all tags every time.
2. The client receives a very large payload (all tags) even if only a subset are shown in the UI.

From profiling, we’ve seen the CPU usage spike in updateDeviceValues() and other functions that handle large arrays or repeated filters. This happens especially when there are many active MQTT tags or many connected clients.

Desired Outcome

• Only fetch and display the tags that are actually needed (for example, 25 per page, 10 or 100 as in the table list), which significantly reduces CPU usage and payload size.
• Implement pagination (or partial fetch) so the server and client handle less data at once.

[unocelli]

Hi, Thanks for the report

[eduardoexact]

Another observation I made is that when I split the same number of tags in multiple MQTT connections, the system is much more responsive.

[henjoe]

For reference, how many tags do you subscribe to in the broker?

[eduardoexact]

I have subcriptions and publish tags. In total there are more than 8000. The server is runing on a Raspberry pi 4. I was able to continue working by splitting the tags in separate coneections.