Skip to content

Flow Image Saving Benchmark

Measures the maximum sustainable throughput of a Node-RED image processing flow across different image sizes and processing modes. This benchmark focuses on the image saving pipeline only -- inference performance is tested separately in its own benchmark.

These results are rough estimates, not exhaustive measurements. The benchmark uses a fixed set of default image sizes and does not test mixed-size workloads. Actual throughput depends heavily on what processing the flow performs. Adding heavier nodes (image processing, model inference) will significantly reduce these numbers.

Results

Throughput in msg/s at the saturation point for each combination. Higher is better.

Machine: i200

1 image per trigger

SizeClean+Train+Log+Both
512x51267.253.530.326.9
1024x102463.736.922.819.2
1024x204860.327.915.413.8
2048x204854.819.913.110.6

2 images per trigger

SizeClean+Train+Log+Both
512x51267.842.719.819.6
1024x102463.827.817.412.9
1024x204860.519.412.19.2
2048x204850.413.310.87.3

3 images per trigger

SizeClean+Train+Log+Both
512x51265.834.719.413.3
1024x102461.419.413.29.9
1024x204858.814.99.57.5
2048x204853.010.17.55.8

4 images per trigger

SizeClean+Train+Log+Both
512x51265.619.913.313.3
1024x102462.417.212.27.2
1024x204859.311.97.25.5
2048x204853.58.05.64.2

Machine: t1000

1 image per trigger

SizeClean+Train+Log+Both
512x51260.051.640.031.4
1024x102452.931.128.621.0
1024x204844.723.819.515.8
2048x204838.115.714.410.0

2 images per trigger

SizeClean+Train+Log+Both
512x51253.538.419.919.8
1024x102449.023.619.413.1
1024x204840.515.912.711.4
2048x204835.810.69.46.4

3 images per trigger

SizeClean+Train+Log+Both
512x51288.342.819.914.5
1024x102475.323.419.310.4
1024x204870.315.312.58.9
2048x204858.010.19.45.8

4 images per trigger

SizeClean+Train+Log+Both
512x51288.236.219.914.5
1024x102475.519.313.27.6
1024x204870.512.29.76.6
2048x204857.58.17.24.2

How to Read the Results

Each table shows throughput in msg/s -- the number of messages the flow can process per second before it starts dropping messages. The value shown is the maximum sustainable rate for that combination, without accounting for other processes that might need heavy processing.

Columns

ColumnMeaning
CleanNo training, no logging -- raw pipeline capacity
+TrainTraining enabled -- model training runs on each frame
+LogLogging enabled -- debug data written per frame
+BothTraining and logging both enabled

Using these numbers

These results represent the capacity of a lightweight flow (resize, light inference, dashboard display, optional training/logging). This benchmark is not exhaustive -- it uses a fixed set of default image sizes and does not test different-sized images within the same run. The numbers are intended as a rough upper bound, not a precise prediction.

Inference is not measured here. The flow uses only a light inference step; heavier models can reduce throughput significantly. Inference performance will be covered in a separate benchmark.

To estimate capacity for your flow:

  • Start from the row closest to your image size and number of saved images per trigger
  • Treat each value as an upper bound -- your real flow will be slower
  • If your required throughput is close to the number shown, you are likely near the saturation point and should test on your actual hardware

The Flow

The benchmarked flow follows this pipeline:

Inject (timed) --> Resize image --> Light inference --> Dashboard --> [Optional: Training] --> [Optional: Log]
  1. An inject node fires at a configurable frequency
  2. The image is resized to the target dimensions
  3. A light inference step runs on the image
  4. The result is sent to the dashboard
  5. If training mode is on, model training runs on each frame
  6. If log mode is on, debug data is written per frame
  7. The image is saved N times (controlled by image count setting)