What we measure
Performance comes down to two platform metrics:
Cutting across both is scaling behavior — how these metrics change as data volume and time ranges grow, and how to query efficiently at scale. This is covered on the Scaling & Best Practices page.
A related concept, data freshness — how recently each signal last changed — is often confused with latency but is a property of your signals, not the platform. It is explained (not benchmarked) on the Ingestion Latency page.
Nexalis pushes data on change (report by exception) with a minimum heartbeat of roughly one value per hour per signal. A tag that hasn’t updated recently is usually a quiet signal — a value inside its deadband or a slow-cadence measurement — not a platform delay. Keep this in mind when a tag’s latest value looks older than you expect.
Headline numbers
For a typical consumer:- Ingestion latency — a value is readable through the API a median of ~5 seconds (95th percentile ~7 s) after it is timestamped at the site.
- Reading the most recent value of one tag — a single API call returns in ~0.64 seconds (full request-to-response round-trip).
- Reading the most recent value of 100 tags in one batched call — ~1.5 seconds.
- Latest 10-minute average for every tag of a large site (~75,000 data points), in a single batched request — ~3 minutes.
- Latest value of every tag active in the last 5 minutes, across a large site (~75,000 data points), in one batched call — ~20 seconds.
Absolute latency depends on your network path to the endpoint. The read figures above were measured from real users across multiple production environments and include roughly 300 ms of network round-trip, so your own times will differ. Use these numbers as ballpark figures rather than guarantees; they are drawn from the detailed benchmark tables on the Query Latency page.
Performance depends on the size of your query
The single biggest driver of query performance is the total volume of values a request returns — the number of data points it addresses multiplied by how many values each has recorded over the requested time window. What matters is the size of the query, not the size of your environment: your deployment may span many sites and hundreds of thousands of data points, but a request is only ever as expensive as the slice of that it actually pulls. You control this through how broadly you scope your selectors and time window. As a rough guide by query size:
Two other factors shape payload — and therefore latency — on top of the number of data points:
- Signal density. A busy site can emit 10–15× more values per tag in its active period than when quiet (for example, a solar site in daylight versus at night). Payload sizing should always assume peak rates. In our test populations the busiest tags exceeded 1,000 values per tag per day, but real-world density can be substantially higher depending on how frequently your signals change and how fast the source samples them — size against your own peak rates, not this figure.
- Time range and data age. Recent data (roughly the last 21 days) is served from a hot storage tier and reads fast. Older history is served from a cold tier with a larger first-touch cost. See Scaling & Best Practices.
Where to go next
- Ingestion Latency — how quickly site data becomes available, and why that differs from data freshness.
- Query Latency — full benchmark tables for read requests and the query shapes that keep them fast.
- Scaling & Best Practices — batching, parallelization, storage tiers, and recommended patterns per use case and environment size.