When the timestamp period is 0.1s, the deployment becomes stuck. How can I optimize it
Sorry, but I'm confused.
So you have an
inject node that injects the
timestamp every 0.1 seconds - yes?
node-red is a single thread. Can I configure multiple threads?
I am not the right person to ask that.
But having the
inject node injecting every 0.1 seconds shouldn't be a problem.
Unless you are doing a lot of things from that.
What are you doing in the flow you trigger every 0.1 second?
There are many nodes in a business flow. If you inject 0.1s, it will cause a lag.
Why are you injecting every 0.1 seconds:
Do you need a fast response to an occasional event or are you processing a large number of events?
I don't mean what is the end purpose, I mean what sort of actions are you performing? Depending what they are, it may be possible to spawn some work into other processes.
Is there lots of database activity for example, or network activity? or what?
If you run the inject at, say, 0.2 seconds, and look at the processor usage, what does it show?
The nodes include camera and image processing nodes.
The camera returns some pictures during the process of collecting the robot motion.
Yeah, there is almost zero chance node will be able grab an image and process it in 100ms. You are just creating a bottleneck.
Instead of hitting it every 100ms, can you not identify when a new image is created and simply run it once instead of running it 10× per second?
Even if it is 300ms, there will be a lag problem. There are other services for image processing.
If your Node-red server cannot cope with the workload then you have to use a more powerful computer or else find a way to distribute the work among multiple devices.
One way might be:
Create images in a directory.
A Node-red instance or OS utility can watch that directory and send the image to another device which is currently free (MQTT to send the data and busy/free status messages)
How often are images created (maximum)?
How long on average does it take to process one image?
I am not surprised. However, you have not provided any details so cannot give you concrete advice.
- How are you currently processing images (what nodes?)
- What processing are you doing (resizing?, cropping?, colour adjustments? ML routines?)
- What size are these images (wxh)?
As I said before, cant you detect when an image needs processing instead of blindly processing every 100ms or 300ms?
Have you timed the flow to see how long it actually takes? Something like this simple flow timer will tell you how long it takes.
But presumaby it takes very little time to process an image which doesn't exist yet.
@baishu really needs to give us some statistics.
How big are the images, how frequent, how soon must an image be processed, etc, etc.
Not using Node-RED directly though you can certainly spawn other threads using Node.js capabilities.
That is highly dependent on what the flow is doing. The actual execution order of things in a Node.js flow can get very complex. While Node.js is essentially single-threaded, it manages multiple actions using a loop mechanism and well defined asynchronous functions. So being single-threaded is a lot less of an issue than might be assumed. Node.js manages the queue of actions and allows the loop to continue while waiting for long-running tasks.
As others have said, if you want help, you need to describe more about the flow so that we can help unpick it.
In addition, a constant, rapid trigger is often a sign of faulty design that might possibly be replaced with an event-driven flow. But without knowing details, it is impossible to say.
The scene we encountered: during the shooting process of the camera, the collection speed is about 1 second and 10 times, and the pictures collected by the camera reach a node (containing some parameters of image processing, this node sends the image parameter content to another processing service, and the processed image will flow to its own stream for other processing.
I tested it. There are two function following. The trigger cycle is set to 0.1, 0.3 or 0.5. In order to test whether the processing can be normal at high frequencies without lagging (the so-called user lagging: long deployment time-the interface mask layer takes a long time during deployment). When an event is triggered, click deploy.
I think there is a problem with the setting of our business scenario. I will reset it here. In fact, what I want to confirm is inject Node. Is it reasonable to set the period execution time to 0.1 or less than 1s?
I've no idea what camera node you are using but I strongly suspect that is the limitation. I've not tested the inject node at those speeds but I can't think of any reason it wouldn't be able to cope just fine. That is easily tested of course.
Yes, it is possible, but not desirable.
As others have said several times, triggering continuously on an event based system is likely due to flawed design.
If you answer the questions we have asked we can likely instruct you on how to improve your flows.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.