Performance troubleshooting - specifically delays in deploy

General
1

I'd like to reduce the time it takes to redeploy, currently about 12-15 seconds.

When I first started with Node-RED, it took a second or two. I understand it's inevitable that as I do more and more, redeploying will take longer, but wanted to gauge reaction here to see if there's anything I can do.

I have turned on trace logging in settings.js.

Sorry if this is obvious but when there's a delay between two lines, is the culprit the item before the delay, or after?

i.e. which line is the cause of this 2 second delay, the first or second?

5 Jul 21:11:10 - [debug] [server:Home Assistant] config server event listener closed
5 Jul 21:11:12 - [trace] Stopped node telegram bot:14f0fdaf.843b92 (3808ms)

The logs total 3763 lines, so probably best not to post them here? But my observations are:

  • Lines starting "stopping nodes" and "stopped nodes" all happen immediately, no delays
  • There's then a 3 second delay within these lines:
5 Jul 21:11:09 - [info] serial port /home/mat/virtualcom1 closed
5 Jul 21:11:09 - [trace] Stopped node serial out:9e0845b5.f18758 (433ms)
5 Jul 21:11:10 - [debug] [server:Home Assistant] WebSocket Connecting http://10.1.1.37:8123
5 Jul 21:11:10 - [debug] [server:Home Assistant] config server event listener connecting
5 Jul 21:11:10 - [debug] [server:Home Assistant] config server event listener closed
5 Jul 21:11:12 - [trace] Stopped node telegram bot:14f0fdaf.843b92 (3808ms)
5 Jul 21:11:12 - [info] Stopped flows
5 Jul 21:11:12 - [info] Starting flows
  • Another 2 second delay here:
5 Jul 21:11:13 - [trace] [flow:fd75c8e.6e63e38] ------------------|--------------|-----------------
5 Jul 21:11:13 - [trace] [flow:a09201df.15c79] start flow
5 Jul 21:11:14 - [debug] [api-current-state:38f8b647.bdac5a] instantiated node, name: undefined
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79] ------------------|--------------|-----------------
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79]  id               | type         | alias
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79] ------------------|--------------|-----------------
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79]  81881b84.f82358  | ui_button    | 
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79]  ffe10c50.9b693   | mqtt out     |
  • Another 2 second delay here:
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79]  6a1b328c.364114  | link in      | 
5 Jul 21:11:15 - [trace] [flow:a09201df.15c79] ------------------|--------------|-----------------
5 Jul 21:11:15 - [trace] [flow:705d403b.f2b8] start flow
5 Jul 21:11:17 - [trace] [flow:705d403b.f2b8] ------------------|--------------|-----------------
5 Jul 21:11:17 - [trace] [flow:705d403b.f2b8]  id               | type         | alias
5 Jul 21:11:17 - [trace] [flow:705d403b.f2b8] ------------------|--------------|-----------------
5 Jul 21:11:17 - [trace] [flow:705d403b.f2b8]  91ae1f5b.663d1   | mqtt in      | 
5 Jul 21:11:17 - [trace] [flow:705d403b.f2b8]  c044f417.257fb8  | switch       |
  • Again here:
5 Jul 21:11:18 - [trace] [flow:acccd118.a467d]  4727a99a.b67ee   | change       | 
5 Jul 21:11:18 - [trace] [flow:acccd118.a467d] ------------------|--------------|-----------------
5 Jul 21:11:18 - [trace] [flow:548d42c.321903c] start flow
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c] ------------------|--------------|-----------------
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c]  id               | type         | alias
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c] ------------------|--------------|-----------------
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c]  4b8be51d.0c0d54  | telegram sender | 
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c]  6a1337c1.a84a88  | link out     |
  • Finally
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c]  2ff263db.d90944  | debug        | 
5 Jul 21:11:20 - [trace] [flow:548d42c.321903c] ------------------|--------------|-----------------
5 Jul 21:11:20 - [trace] runtime event: {"id":"runtime-state","retain":true}
5 Jul 21:11:20 - [info] Started flows
5 Jul 21:11:20 - [trace] runtime event: {"id":"runtime-deploy","payload":{"revision":"79a10748667bdbb944a0cf62c14d60a1"},"retain":true}
5 Jul 21:11:21 - [debug] [server:Home Assistant] WebSocket Connecting http://10.1.1.37:8123
5 Jul 21:11:21 - [debug] [server:Home Assistant] config server event listener connecting
5 Jul 21:11:21 - [debug] Flushing localfilesystem context scope global
5 Jul 21:11:21 - [debug] Flushing localfilesystem context scope b6f158a2.116b88:fa3892e2.c6cfd

Any obvious things I can temporarily remove to test?

Should I just throw more processing power or memory at it?

Node RED is running on Ubuntu in a VM on a Windows host, with 96GB of RAM and XEON processor so I can probably assign more resources, but wanted to check people's initial reactions here first!

Thanks

2

Without knowing how big and complex your flow is it is very difficult to gauge how much of a "problem" this is.

3

Also what kind of deploy are you doing? Full or partial?

4

Now I feel a bit silly - this is a good point. Far quicker doing a deploy of modified nodes - as in, half a second. Thank you.

OOI - why would you want to do a full deploy?

5

Occasionally, some nodes really need a kick to get them into shape. Also, a full redeploy should clear out any in-memory data including global/flow variables I think.

I always do a minimal deploy unless something looks wrong afterwards.

1 Like