You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I updated the addon from v18.0.5 to v18.1.1 on October 10. In Node-Red I am running a flow that involves polling entities via the get entities node at regular intervals (currently 5 s). I have around 1600 entities.
On v18.0.5 this did not produce a noticeable performance impact. However now the call on get entities produces up to 100% of load on one CPU core.
I was able to pin-point the issue to exactly this flow by disabling only this this flow. This took the CPU load of the node red addon back to 1-2% of CPU time.
Here you can see how CPU load changed once I upgraded from v18.0.5 to v18.1.1 on October 10. Bear in mind that these are by now average readings of the complete cores dedicated to HA. For reference I run HAOS within a VM on an Intel-based x86 NAS.
The flow in question:
Note: I have replaced the regex with string matching which hat no discernible effect.
Further note: I realize that this might not be the most performant modeling of that flow that I can do, but it's quite effective and allows me to evolve my HA setup without having to maintain something on top, such as labels, On v18.0.5 this approach had no measureable performance impact.
Expected behavior
CPU load of 1-2% when using get entities node to match through 1600 entities at 5 seconds intervals.
Actual behavior
CPU load of up to 100% on one core when using get entities node to match through 1600 entities at 5 seconds intervals.
Steps to reproduce
Have/obtain a setup of around 1000 entities
Create an inject node with an interval of 5 seconds
Connect the inject node to a get entities node that iterates through all entities via entities.friendly_name and their state property
Watch CPU load
(To compare, do the same on v18.0.5)
Suspicion
I believe that the get entities node evolved with v18.1 and is now able to also comb through labels, floors, etc. Maybe this new implementation has introduced a side-effect or other drastic performance penalty?
The text was updated successfully, but these errors were encountered:
Considered closed as package.json already references node-red-contrib-home-assistant-websocket 0.74.2 on main branch which should resolve the issue for the next release.
Problem/Motivation
I updated the addon from v18.0.5 to v18.1.1 on October 10. In Node-Red I am running a flow that involves polling entities via the get entities node at regular intervals (currently 5 s). I have around 1600 entities.
On v18.0.5 this did not produce a noticeable performance impact. However now the call on get entities produces up to 100% of load on one CPU core.
I was able to pin-point the issue to exactly this flow by disabling only this this flow. This took the CPU load of the node red addon back to 1-2% of CPU time.
Here you can see how CPU load changed once I upgraded from v18.0.5 to v18.1.1 on October 10. Bear in mind that these are by now average readings of the complete cores dedicated to HA. For reference I run HAOS within a VM on an Intel-based x86 NAS.
The flow in question:
Note: I have replaced the regex with string matching which hat no discernible effect.
Further note: I realize that this might not be the most performant modeling of that flow that I can do, but it's quite effective and allows me to evolve my HA setup without having to maintain something on top, such as labels, On v18.0.5 this approach had no measureable performance impact.
Expected behavior
CPU load of 1-2% when using get entities node to match through 1600 entities at 5 seconds intervals.
Actual behavior
CPU load of up to 100% on one core when using get entities node to match through 1600 entities at 5 seconds intervals.
Steps to reproduce
Suspicion
I believe that the get entities node evolved with v18.1 and is now able to also comb through labels, floors, etc. Maybe this new implementation has introduced a side-effect or other drastic performance penalty?
The text was updated successfully, but these errors were encountered: