Single-cell scale test · gate G1C

We load one cell of a million test mailboxes with far more mail than a real deployment sends, and see whether it keeps up. These are the live numbers from that test, straight from its own monitoring, a few seconds old. Between runs the page sits idle.

Mail arriving

—

target ≥ 1,850 msg/s

Mail apps connected at once

—

target ≥ 200,000

Slowest 1% of API calls

—

target ≤ 250 ms, server side · as the client sees it —

Slowest 5% of deliveries

—

target ≤ 5 s · the middle one takes —

Live trends · last ~15 min

Mail arriving —target ≥ 1,850/s

Slowest 1% of API calls —target ≤ 250 ms

Slowest 5% of deliveries —target ≤ 5 s

Mail apps connected —target ≥ 200k

Inside the cell · measured on the server: writing the message and committing the change

Busiest it has been

—

messages a second, sustained

Coming in → going out

—

messages a second, each way

Still in hand

—

accepted, not yet delivered or failed

Delivery time: middle / slowest 5% / slowest 1%

—

time on the server, per message

Slowest 5% of deliveries, on the server —target ≤ 5 s

Messages still in hand —flat means it is keeping up

Rates and errors

Taken in

—

messages a second

Put in a mailbox

—

messages a second

Asked to try again later

—

messages a second

Errors seen by the test clients

—

smtp/jmap/idle

The one that matters · nothing accepted goes missing

Messages we said yes to	—
…that reached a mailbox	—
…that bounced or were deferred	—
…still in hand (should stay small)	—
API calls answered	—

This is a read-only snapshot, copied out of the test's own monitoring over a private network. Nothing internal is reachable from this page. The targets come from the ZephyrAB architecture document (gate G1C): 1,850 messages a second arriving, 200,000 mail apps connected at once, the slowest 1% of API calls under 250 ms, the slowest 5% of deliveries under 5 s, all held for 24 hours without losing a message we accepted. Two measurements to read carefully. The API figure is taken on the server (zephyr_jmap_request_seconds) and does not include the time spent checking the caller's password, which is real time a user waits — the figure as the client sees it is shown next to it on the card. The delivery figure is taken by the test clients, not the server, so it includes the network.