Skip to content

Performance Baselines

These are recorded results from Flowgate's own benchmark and soak runs, published as measured. Each result names the date it was recorded and the environment it ran on. Nothing here is extrapolated: where a run found a limit, the limit is documented too.

Reference environment

All chain results below were measured on the permanent Flowgate validation chain, built deliberately from modest hardware:

  • Two virtual machines, each with 8 CPU cores and 16 GB of memory, running Debian 13.
  • One machine runs a Tier 1 node, the other a relay node. The relay connects to the Tier 1 node over OPC UA Reverse Connect, exactly as it would across an OT boundary.
  • The relay simultaneously maintains 100 independent OPC UA collection connections, each mounted as its own external server with its own namespace. In the lab these connections terminate on two physical OPC UA server instances, one serving a 100,000 tag address space, so the node carries the same workload as collecting from 100 separate servers.
  • A test client connects to the Tier 1 node and consumes everything through the chain.

This is a two-hop, fully federated setup: every value travels device server, relay, Reverse Connect, Tier 1, client.

Sustained throughput soak (recorded 2026-07-25)

A two hour continuous run on a Flowgate development build of 2026-07-25, with 10,000 monitored items at 1 second sampling spread over all 100 connections:

Measure Result
Duration at full load 2 hours continuous
Monitored items delivering 10,000 of 10,000
Sustained delivery rate 9,649 updates per second, fleet average over the whole window
Total values delivered 59.7 million
Bad quality values 0
Stalled connections 0 of 100
Tier 1 node peak memory 1.5 GB
Relay node peak memory 2.7 GB

The address space behind this run holds 100,000 tags. Browsing and monitoring against a folder of that size, through the full chain, is part of what the run validates.

Scale ceiling (recorded 2026-07-25)

The companion run on the same build and hardware pushed item count instead of rate: 100,000 monitored items were requested at 10 second sampling. The run established a documented limit:

  • 81,584 items were created and then delivered for the full two hour window, at a sustained fleet average of 6,101 updates per second (35.6 million values, zero bad quality on delivering items).
  • Item creation stalled at roughly 82,000 concurrently monitored items on this hardware; the remaining requests timed out during setup. Connections that had completed setup were unaffected for the rest of the run.

What the ceiling means

On reference class hardware (8 cores, 16 GB per node), plan for up to about 80,000 concurrently monitored items per chain. This is a creation path limit found under a deliberate worst case: all 100,000 items requested at once through a single chain.

Data routes (recorded 2026-08-21)

Data routes are how a node collects a chosen set of tags at a chosen rate and delivers them to a destination: see Data Routing. The recorded results:

  • A single data route with 10,000 browse-expanded tags at a 1 second cadence sustained approximately 9,200 records per second of live collection on the reference chain. The limiting factor in that run was the source server, not the routing engine.
  • The routing engine itself is not the bottleneck at these rates: the in-process pipeline (ingest, bus, route matching, dispatch) measures approximately 630,000 messages per second on an 8 core x86 reference machine, with no network or serialization in the path.
  • Route matching cost grows linearly with the number of configured routes: measured at roughly 1.5 microseconds per message with 10 routes and 48 microseconds with 1,000 routes on the same reference machine. At typical route counts, matching is a negligible share of the pipeline.

Store and forward delivery between two nodes was measured on the same two machine chain, with the spool and receiver on their default settings:

  • A single store and forward uplink sustains approximately 5,000 records per second end to end (collection, spool to disk, push over the chain, durable receipt on the receiving node), measured under an offered load of roughly twice that.
  • The collection and spooling side alone sustains approximately 9,200 records per second; the delivery pipe, which waits for durable acknowledgement of every batch, is the bottleneck. Values above the sustained rate are not lost: they accumulate in the spool and drain when load falls.

For how store and forward protects data during outages, see Store and Forward.