Server-side request time
The published P50-P99 figures measure concurrent API work on the production server path while ingestion is active. They exclude a buyer's browser, internet route, DNS and public TLS termination.
Benchmark methodology
What the 1M profile proves.
The reference result is an engineering workload with explicit reliability gates. It is not a claim that every public internet request completes in 13.73 ms.
1,002,938 events/sServer-side P95: 13.73 ms20.68 ms P99Zero failures
Test conditions
Reproducible workload definition
- Host
- AMD EPYC 4464P, 12 cores / 24 threads
- Memory
- 128 GB DDR5 ECC
- Storage
- 2 x 960 GB NVMe, software RAID 1
- Network
- 1 Gbps host interface
- Event shape
- Structured device telemetry with nested identity, state and measurements
- Representative raw size
- 1,342 bytes per JSON envelope; values vary by sequence and payload
- Batching
- 128 events per capsule, 8 coordinated publishers
- Working set
- 7,000 synthetic device identities across 16 ingest partitions
- Duration
- 30 seconds at the 1M-events/s profile; 30 million published events
- Durability
- JetStream publish acknowledgement plus native pipeline drain verification
Latency scope
Server-side and public network time are separate measurements.
Customer-perceived request time
Public measurements include client-to-server network time, TLS and ingress. They vary by endpoint, payload size, route, cache state and client location, so Jylus reports them independently from server-side request time.
Sustained validation
Long runs will be published separately.
The completed reference result covers 30 seconds. Jylus will not extrapolate it into a sustained-load claim. Each longer profile will publish resource usage, queue depth, tail latency, failures and final drain state when the run is complete.
30 minutes
Validate memory stability, queue equilibrium and tail latency under sustained load.
- Memory
- Start, peak and end
- Queues
- Peak and final depth
- Latency
- P50, P90, P95 and P99
2 hours
Validate longer-term resource stability, compaction behaviour and recovery margin.
- Memory
- Start, peak and end
- Queues
- Peak and final depth
- Latency
- P50, P90, P95 and P99
Measured result
Latency and reliability gates
Accepted rate1,002,938 events/s
P506.59 ms
P9011.45 ms
P9513.73 ms
P9920.68 ms
Failures0
Redeliveries0 added by the run
Dead letters0 added by the run
Pending queue0 after verified drain
Queryability
Reads remained active during ingest.
The gate ran concurrent API requests while events were being accepted, then required every governed pipeline queue to drain without failures, new redeliveries or dead letters. The test verifies continued query service and final zero backlog. It does not claim that every individual event was queried immediately after its own publish.