Measure how long your flow takes to execute

General
1

Hi,

How do you measure how long it takes to execute your flow? (Understand that there are loops and other factors) But there are various ways of doing something, some take more time than others.

So basically looking at a way to measure if I have improved my flow.

Thanks

2

I would attach a timestamp to a message property like msg.timestamp or a flow var at the start of the flow and put a function node at the end that gets a new timestamp and calculates the difference between the two and outputs it as msg.runtime for example.

Johannes

3

...I'd use this node: https://flows.nodered.org/node/node-red-contrib-interval-length ... note that it can use the flow start for a trigger trigger as well.

1 Like
4

I'm not sure if this node can be used for this purpose, but perhaps you could...
I developed that node for measuring the timings between successive messages. Optionally you can measure the timing between the flow start and the 'first' message.
But if it is useful to measure the performance of a flow, please share here how you did use it. Thanks!

P.S. Have not used it myself, but perhaps the Node-RED metrics could be used to compare timings of flow versions?

1 Like
5

I suppose any readings obtained by either adding timestamps or using metrics will only be a rough guide, as their granularity is displayed in milliseconds.
So unless the flow is particularly slow, the results are not going to be accurate.

6

Thanks, from the metrics I can see the time the first node starts to where the last node stops, it is a bit of a manual process to determine the time it takes, but never the less a way to tell.

Thank you

1 Like
7

As with many metrics/logs the expectation was that at some point someone would write a nifty tool to help analyse the log, to help show hotspots, bottlenecks, breaks, etc etc... but you know, time, time, time.

1 Like
8

That will be brilliant :smiley:

If I calculate manually my flow it takes abort 4576ms +/- (fairly constant over to instances).

The fist node I could predict (as it is a inject node that starts the process) but the last node were a debug that I did not expect to be the last, it is consistently the last one.

Will be nice to see the hotspots, bottlenecks, breaks, etc, as to do these manually are difficult.

9

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