Performance

Benchmark Methodology

How Twinise architecture, latency, and throughput figures should be measured and presented.

Why This Page Exists

This page documents how performance claims should be interpreted and validated.

Important: the current values shown in marketing UI are illustrative placeholders, not contractual production guarantees.

Claim Classification

When you publish numbers, label each one explicitly:

  • Target: an engineering goal not yet validated in production.
  • Lab-tested: measured in controlled test environments.
  • Typical: observed under representative customer-like workloads.
  • Maximum observed: peak measured value under defined constraints.

Avoid publishing unlabeled single-value claims.

Required Metadata Per Metric

Every public metric should include:

  • Workload profile (event size, message frequency, payload mix)
  • Topology (device count, gateways, region, network path)
  • Runtime versions (gateway firmware, cloud runtime, Unreal connector version)
  • Time window (sample period, percentile used, outlier treatment)
  • Measurement method (tooling, sampling interval, aggregation logic)

Suggested Baseline Table Template

Use this structure when replacing placeholders with validated results.

| Metric | Value | Label | Environment | Notes | | --- | --- | --- | --- | --- | | Ingest rate | TBD | Target | Lab | Replace with measured p50/p95 throughput | | End-to-end latency | TBD | Lab-tested | Lab | Include p50/p95 and route definition | | Unreal update tick | TBD | Typical | Staging | State scene complexity and actor count |

Publishing Rule

Before a value appears on homepage, product pages, or sales collateral:

  1. Record test run metadata in an internal benchmark log.
  2. Attach the run date and software versions.
  3. Have engineering and product approve the wording and label.
  4. Update this page and link it wherever the metric is shown.

Related References