Allow random range delay

Core Development Feature Requests
,
1

I'd love the option to delay & rate-limit messages using a range to select a random amount of time.
For example: delay messages to 3-6/sec, so that each message in the queue will wait between 3 to 6 seconds.

It helps tremendously when dealing with a rate-limited API several times down the line, because it alleviates the need to micro-manage the delays.

2

Welcome to the forum @eden881

You can use a Random node (node-red-node-random, you may need to install it in Manage Palette) to insert a msg.delay between 3000 and 5000 (milliseconds) into every message.
The delay node has an option to override the delay with msg.delay.

image
image540×132 3.48 KB

image

In rate-limit mode there is an option to accept msg.rate. I don't know what effect this has!

image
image601×314 13.3 KB

3

Oh, that’s clever!
I didn’t know about the random node. If it works in rate-limit mode it solves my issue completely.
I’ll give it a try, thanks.

4

Why does a random delay help ? If you know the ratelimit further down the flow why not just apply it using the rate limit mode of the delay node ? It is only setting the maximum rate allowed.

5

Let’s say the API allows up to 1 msg per second, and I hit it at two points in my flow.
If I set both delay nodes to rate limit at 1/sec, I’ll have a situation where both delay nodes will essentially fire at almost the same time, because each message is delayed at the first stop and then clears the second stop condition.
In my case I also split messages between the API calls which worsens this issue significantly. Using randomness helps to minimize the chance of this issue.

More info can be found here (this article is about back off strategies, but the jitter part applies here too):

6

If you are using multiple API calls (ie different flows) but have an overall rate limit then you could divide the rate limit across each delay node (in rate limit node) ie assign half to each (if two flows) etc.

Or you could use a single rate limit node and feed all flows through it - using the msg.topic to identify each (see below)... eg set msg.topic to the url for the api so they are unique - but then after the delay node - move the topic to msg.url before calling the http request node... or something like that.
eg

image
image910×560 21.2 KB

7

You could make a reusable flow via a link-in / link-call (like a single subroutine that only has a single delay node http-request)

This makes it easier to maintain too

[flow 1 do something]----[link-call: "API"]----[do stuff with response]
[flow 2 do something]----[link-call: "API"]----[do stuff with response]
[flow 3 do something]----[link-call: "API"]----[do stuff with response]

[link-in "API"]----[rate limit]----[http-request]----[link-out (return)]

8

After some experimentation this seems to be the best solution to my issue.
I didn't know about link out's return mode, thanks!

I actually only used the rate limit node in the 2nd flow since my web requests hits different API routes. It works great.