OuroPlatform Benchmark

Modern smart-grid solutions depend on reliable, scalable, and secure data acquisition. Whether it’s electricity, gas, water, or heat, utilities increasingly require platforms capable of collecting millions of datapoints in minutes—not hours.

In this article, we share a detailed benchmark of OuroPlatform, our high-performance, protocol-agnostic data collection and monitoring system.

We simulated 1.2 million devices, executed 1.2 million jobs, and measured how fast the platform could read and store DLMS profile data at scale.

If you're evaluating technologies for AMI, HES, or large-scale DLMS data acquisition, this benchmark will give you a clear performance reference.

What is OuroPlatform?

OuroPlatform is a next-generation application for remote data collection and monitoring. It is designed for:

• High-volume data acquisition
• Ultra-fast job processing
• Top-tier security
• Support for a wide spectrum of communication drivers

Tested System

OuroPlatform is a component-based system optimized for efficiency and speed. All components communicate via gRPC or through a messaging layer. Communication with DLMS Meter Simulator uses DLMS protocol with security suite 2 enabled. Whole communication is encrypted and authenticated using AES-GCM-256 as required by DLMS specification, every simulated meter has its own set of cryptographic keys.

Glossary

• Device - Term for a meter. Devices have different types (electric/gas), manufactures, etc.
• Periodical profile - A time-series dataset where all values are aligned to a specific interval (e.g., 15 minutes) with timestamps aligned to the clock starting at 00:00.
• Job - A unit of work instructing OuroPlatform to do an activity with a device.
• Simulator - Our DLMS Meter Simulator, a tool that simulates a real-world meter including behavior, data structures and delays. A single simulator instance can simulate tens of thousands (even millions) of virtual meters.
• Virtual meter - A single virtualized meter simulated by a Simulator instance.
• Driver - A component of OuroPlatform responsible for communicating with a specific types of devices using appropriate communication protocols (like DLMS).

Benchmark Scenario

The benchmark focuses on the following scenario:

Read all configured 15-minute and 10-minute profiles for one full hour (4 and 6 values per profile) for 1.2 million devices, as quickly as possible.

Benchmark Setup

Test Environment

The benchmark was performed in our lab on physical hardware machines running:

• Kubernetes cluster: 3 master nodes, 4 worker nodes
• Ceph storage cluster: 2-node for HA storage (running outside Kubernetes)
  • All data are stored in 2 replicas (storage-level HA mode)
• PostgreSQL cluster on Kubernetes with TimescaleDB extension via CloudNativePG
  • 2 nodes (database-level HA mode), primary+synchronous replica
  • Data stored on Ceph
  • WALs stored locally on the hosting node
• NATS queue cluster on Kubernetes
  • 3 nodes (queue-level HA mode), RAFT distributed algorithm
  • Data stored on Ceph
• OctopusMQ queue cluster on Kubernetes
  • 3 nodes (queue-level HA mode), RAFT distributed algorithm
  • Data stored on Ceph
• Network
  • Kubernetes nodes: bonded 2x1 Gbps metal connection (2Gbps total)
  • Ceph cluster (Ceph-to-Ceph): 10 Gbps optical connection

To simulate electric meters, we used our DLMS Meter Simulator that simulates virtual electric meters. To mimic the real-world behavior, several random factors such as random packet delay (250 ms to 1 s) were implemented.

Whole system setup was set similarly to a real world deployment across distributes cluster, running 2 database and queue replicas in active-active HA mode, all data were stored on 2 Ceph nodes in active-active HA mode. PostgreSQL data are asynchronously backend up to a NAS.

Benchmark resources

In total 50 CPU cores, 137 GB RAM was reserved in the cluster:

• OuroPlatform core components had: 16 CPU cores, 25 GB RAM
• OuroPlatform driver components had: 24 CPU cores, 64 GB RAM
• PostgreSQL had: 10 CPU cores, 48 GB RAM

Test case

The benchmark consisted of scheduling 1.2 million jobs via OuroPlatform API, then read the requested data from the simulated meters, and store them as fast as possible.

A total of 1.2 million virtual meters were simulated in parallel:

• 24 simulator instances
• 50,000 virtual metes each

Each device contains six (6) 15-minute profiles and eighteen (18) 10-minute profiles and simulates the following OBIS codes:

• 15-minute profiles:
  • 1-0:1.4.0
  • 1-0:2.4.0
  • 1-0:5.4.0
  • 1-0:6.4.0
  • 1-0:7.4.0
  • 1-0:8.4.0
• 10-minute profiles:
  • 1-0:12.4.0
  • 1-0:12.6.0
  • 1-0:12.3.0
  • 1-0:21.4.0
  • 1-0:22.4.0
  • 1-0:23.4.0
  • 1-0:24.4.0
  • 1-0:31.4.0
  • 1-0:41.4.0
  • 1-0:42.4.0
  • 1-0:43.4.0
  • 1-0:44.4.0
  • 1-0:51.4.0
  • 1-0:61.4.0
  • 1-0:62.4.0
  • 1-0:63.4.0
  • 1-0:64.4.0
  • 1-0:71.4.0

Requested data covered a 1-hour period, resulting in:

• 28.8 million datapoints for 15-minute profiles
• 129.6 million datapoints for 10-minute profiles

The precalculated number of parallel connections to read devices within an hour was 8000.

To distribute the load across the Kubernetes cluster, these connections were covered by 16 driver instances, each supporting up to 500 parallel connections. The number of drivers was scaled automatically between 0 and 16 based on number of remaining jobs.

Measuring and Metrics

OuroPlatform exposes a rich set of Prometheus metrics. We collected metrics from:

• OuroPlatform components
• NATS
• PostgreSQL

We focus on the USE and RED metric methodologies:

• USE (Utilization, Saturation, Errors)
• RED (Rate, Error, Duration)

We also measured total completion time, defined as:

Time from initiating the bulk to the moment the last datapoint is successfully written into PostgreSQL.

Results were consistent across hundreds of runs, with a variance of ≈ 3%.

Benchmark Results

Total Duration

The system finished the entire batch of 1.2 million jobs in 1 hour, 24 minutes, and 30 seconds.

Data Collection Phase

All data from 1.2 million meters was collected in 50 minutes and 30 seconds.

The graph below shows the datapoint (rows in the graph) processing speed over time.

Job completion averaged ≈ 400 jobs/second.

The graph below shows the speed at which the jobs were completed in this system configuration.

Data Storage Phase

Data was stored asynchronously as soon as the first device data arrived from the driver.

After all jobs (interactions with meters) were finished, the system required an additional 34 minutes to write the remaining data into the datastore.

Network throughput

• Peak traffic: 52 Mb/s
• Average during meter communication: 44 Mb/s
• Average during data-saving phase: 21 Mb/s

Resource Utilization

Every component of the tested system had reserved memory and CPU. This was over-provisioned and all components together had:

• Peak memory usage: 32 GiB
• Average memory usage: 31.8 GiB
• Peak CPU usage: 22.8 cores
• Average CPU usage: 21.9 cores

Conclusion

The benchmark demonstrates that OuroPlatform can read and process over 1.2 million devices and 158.4 million datapoints in under 90 minutes, even on a mid-sized lab cluster. The 10 Gbit network may seems to be overkill, but it provided low latencies for all components distributed across servers.

The job queue and related set of communication drivers read all meters in 50 minutes and 30 seconds.

The data was temporarily stored in their raw form in a data processing queue. An asynchronous component processed the raw data and saved them to the database. This process runs always on the background, and continued from the first finished readout until the end of the test.

When all 16 driver instances were running, the resource requests were higher. For the rest of the run, the drivers were scaled down, saving reserved resources.

Key findings:

• PostreSQL was the main bottleneck
  The primary node operated at 100% CPU and throttling was observed.
• Adding more CPU alone won’t help
  Increasing PostgreSQL compute capacity simply moves the bottleneck to a different component.
• OuroPlatform processed jobs extremely efficiently
  Communication with devices finished in only 50 minutes, leaving the rest of the time for data persistence.

Summary

This benchmark confirms that OuroPlatform can:

• Handle more than a million devices
• Maintain predictable throughput
• Support heavy DLMS/COSEM workloads

If your utility, integrator, or AMI project requires high-performance, resilient, and secure data acquisition at large scale, then OuroPlatform provides a reliable and modern foundation.