Part 10 of 12
Performance, scale & security
Measured capacity and speed, the path to scale for large-industry data volumes, high availability, users and roles, and layered security.
19
Users, Roles, and Security
Identity and Access
- Users with system roles; 12 permission domains × 7 actions (view, create, edit, delete, control...)
- Tiered access keys per project (system, admin, level 1-3 user); read-only keys for display screens
- Login with username and password, signed tokens, token exchange with the admin session; login/logout and settings changes recorded in the event log
Secure Control
- Commands to equipment only with control permission and password confirmation (a short, 60-second session)
- Each command executes only once (unique key), and the device's receipt is recorded
- Smart-assistant actions only with user confirmation; command-issuing logic requires a second confirmation
- Complete data separation between projects; allow-list of origins; encrypted communication (HTTPS/WSS); customer-bound licensing
31
Capacity, Performance, Scalability, and Reliability
Measured Real-Time Performance
The test was run on the system's current version and an ordinary server (6 virtual cores, 16 GB memory) with the real database of 3 projects: 3,456 points of a data center, at decreasing update intervals, through the real-time publishing engine to WebSocket.
| Update Interval per Point | Target Load (values/second) | Achieved Load | Lost | Input Queue |
|---|---|---|---|---|
| 1 second | 3,456 | 3,623 | 0 | Empty |
| 250 ms | 13,824 | 13,941 | 0 | Empty |
| 100 ms | 34,560 | 34,679 | 0 | Empty |
| 50 ms | 69,120 | 69,165 | 0 | Empty |
| 20 ms | 172,800 | 117,776 (test hardware ceiling) | 0 — via latest-value coalescing | Empty |
Result: on an ordinary server, the publishing engine delivers roughly 70,000 updates per second with zero loss to all connected users, and at higher loads (up to ~120,000/second) it still delivers each point's latest state via "latest-value coalescing." The full processing path (calculation, limits, logic, storage) was measured in this test, with equipment simulated over WebSocket, at about 2,500 value changes per second for a single node — equivalent to monitoring tens of thousands of points with report-by-exception; optimizing this path for very large sites is on the roadmap.
Architecture for High Data Volume
Isolation and Load Distribution
- Each project (site, process unit, building) has its own memory context, keys, sessions, and independent history database; the growth of one site does not affect another
- Very large sites (refineries, petrochemical plants, power grids) are divided into independent units; each unit has its own polling interval and logic
- Companion services (catalog, AI, map) are deployed on separate servers so they don't load the core
- Per-device polling intervals and report-by-exception with a deadband reduce data volume at the source
High-Volume Storage
- Enterprise PostgreSQL with batched writes (every 5 seconds for current values, every 60 seconds for history)
- Monthly history partitioning: queries on recent data stay fast, and archiving/deleting old data happens without locking
- A 10,000-message input queue absorbs sudden bursts from equipment; no message was dropped from the queue in testing
- "Latest-value" coalescing in publishing: users always see the freshest state, even under heavy load
High Availability (HA)
- Database: streaming replication and a standby server in PostgreSQL; point-in-time recovery from backup
- An application node on standby with the same version and configuration; settings export/import for fast failover
- The state of state machines and scenario deadlines persists in the database; after a node failover, logic resumes from the same point
- Updates with the previous version pinned and one-command rollback
Clustering
- Today: database clustering (PostgreSQL HA), separation of services onto distinct servers, splitting large sites into independent units
- On the roadmap: active-active clustering at the application layer, with projects distributed across nodes and horizontal aggregation nodes — the system's project-centric architecture is designed for this distribution
The figures in this chapter are the system's real timings and capacities, and the basis for sizing project estimates.
| Component | Value | Effect |
|---|---|---|
| Driver polling cycle | Due equipment every 10 seconds; each device has its own interval (from a few seconds to minutes) | Network load tuned per device |
| Input / output / SMS queue | 10,000 / 1,000 / 1,000 messages | Absorbs input bursts without loss |
| Current-value writes | Batched every 5 seconds | Database load independent of data rate |
| WebSocket publishing | Every 75 ms, batches of up to 500 events | Sub-second latency in the browser |
| Browser refresh | 100 ms (visible points) / 600 ms (the rest) | High-point-count pages stay smooth |
| Backend fallback sync | Every 8 seconds (REST), full sync every 5 minutes | No dependency on WebSocket in restricted networks |
| Heartbeat and reconnection | 5 seconds; exponential 5 to 60 seconds; dead-connection detection at 15 seconds | Stability behind NAT and proxies |
| History | Independent database per project; monthly partitioning; batched inserts every 60 seconds | Data grows without slowing queries |
| Polling history | 90 days, with nightly cleanup | Troubleshooting device connectivity |
| Energy | Real-time every 5 seconds; demand every 15 minutes; hourly/daily/monthly | Billing-ready reports |
| Reference sample for this document | 3 projects · 427 devices · 3,964 points · 32 dashboards | On a 4-core / 8 GB server |
Reliability
- A fault in one point or device does not stop the polling loop for the rest
- The current state of state machines and scenario deadlines is preserved across restarts
- Commands use a unique key; updates have automatic rollback
- Daily backups of databases and files; rotating log retention
Scalability
- More projects = a separate history database for each
- Companion services (catalog, AI, map) can be deployed on a separate server
- Profiles and modules are activated without a new installation
- For large sites: per-device polling intervals and selective point subscriptions
35
Security — Layer by Layer
1 · NetworkHTTPS/WSS only, through the TLS gateway; internal services are not reachable from outside; an allow-list of origins
2 · IdentityLogin with username/password; signed tokens; a separate admin session for the console
3 · AuthorizationRoles and 12×7 permissions; project key with a level (system, admin, user 1-3)
4 · ControlControl permission + 60-second password confirmation + unique key + device receipt
5 · AssistantEvery write goes through a confirmation card; command-issuing logic stays disabled until a second confirmation; fabricated results are rejected
6 · AuditEvent log: login/logout, settings changes, manual commands; rotating logs
Data
- Complete project separation across the API, WebSocket, history, and media
- Daily backups; restore from snapshot; configurable retention
- Data stays on the customer's server; the language-model provider is selectable, or can be local
Secure Operations
- Updates with the previous version pinned and one-command rollback
- Customer-bound licensing with an expiration date
- SNMPv3 with authentication and encryption for equipment; Tuya with AES; Redfish over HTTPS
- Recommended: a separate VLAN for equipment, VPN for remote access, changing default passwords after installation
See the Digital Twin live
The live ArgBMS demo with real 3D twins, dashboards and logic.