Skip to content
Use case

OCPP load testing and stress testing

Your CSMS needs to handle many concurrent charge points without dropping connections or losing transactions. OCPPLab runs up to 100 virtual chargers at once against it, so you see how it behaves under concurrent load before production.
Animated example of an OCPP load test in OCPPLab: a run configured for 100 virtual chargers on OCPP 2.0.1 for 600 seconds. The ramp line climbs to 100 chargers and holds while the run is Running, and the p95 latency table lists OCPP actions with a dash for each value. It shows the shape of a run only: no measured values.

Why OCPP load testing matters

Every OCPP charge point maintains a persistent WebSocket connection to your CSMS. At scale, that means managing many long-lived connections, each sending periodic heartbeats, status notifications, and meter values.

A CSMS that works with a handful of test chargers can still fail once many connect at once.

Common failures at scale

  • WebSocket connection pool exhaustion as connections growShows in Connection failures
  • Message processing latency spikes when many chargers send at onceShows in p95 latency
  • Database write contention on MeterValues and transactionsShows in p95 latency
  • Heartbeat timeout storms on network hiccupsShows in Connection failures
  • Memory leaks from improperly closed connections
  • OCPP message queue overflow under sustained loadShows in Check pass rate

How it works

The fleet size field set to 100 virtual chargers and the duration to 600 seconds.
Step 1

Pick a workflow and chargers

Pick one saved OCPP workflow and how many virtual chargers run it at once, from 1 to 100.

The workflow picker with the BootNotification → TransactionEvent workflow selected.
Step 2

Set duration and ramp-up

Run for 10 to 600 seconds, with every charger starting at once or ramping up over a period you choose.

A running load test with its ramp line part way up.
Step 3

Run the test

Each virtual charger connects over WebSocket and repeats the workflow's OCPP messages, such as BootNotification, StatusNotification, Heartbeat, and transactions, until the run ends.

The results table: p95 latency by OCPP action, each value a dash; no measured values.
Step 4

Analyze results

After the run, see iterations per minute, the check pass rate, connection failures, and p95 latency for each OCPP action, with the frames of failed steps.

What is OCPP load testing?

OCPP load testing measures how a Charging Station Management System (CSMS) performs under high volumes of concurrent charge point connections. Each OCPP charge point maintains a persistent WebSocket connection, sending heartbeats, status notifications, meter values, and transaction messages. Under concurrent load, CSMS platforms fail in ways a handful of test chargers never show. OCPPLab load mode runs one saved OCPP workflow on up to 100 virtual chargers at once for 10 to 600 seconds, with a constant or ramping start. Results show iterations per minute, the check pass rate, connection failures, and p95 latency per OCPP action.

Run 100 virtual chargers against your CSMS

Start them together or on a ramp, for 10 to 600 seconds, and read p95 latency per OCPP action before production rollout.

Start load testingBook technical demo

Last updated: