Demo
Demo

Knowledge base

PMTA knowledge base›Metric§ 5.3

Latency on reception

inbound performance timings
How long submission takes on our side

The number of submissions and the time by reception stage.

It shows the node from the side the submitting system sees it: how long accepting a message takes. Slow reception holds back the platform even when delivery goes normally.

The main trap is taking a snapshot for a history. The metric describes the moment of polling. Everything that happened between two measurements and managed to end will not get into either of them. For events there is accounting, for state — these numbers.
What the Hub does. It does not collect it — this metric is not among those the node poll reads.

⚠️ None of our modules measures submission latency — neither from the node’s side nor from the platform’s side.

Recommended values

What to compare with:

Value Compared with
current value the usual one for this node, not the neighboring one
peak the ceiling, if there is one
growth the growth rate, not the absolute number

Fleet nodes are not directly comparable: they have different hardware, different addresses and a different mix of receivers. It makes sense to compare a node with itself over time.

The comparison advice is ours. From the manual here come the metric’s composition and its units of measurement.
Example configuration
# the metric comes in the status snapshot
curl -s "http://127.0.0.1:8080/status?format=json"pmta show status
The highlighted line returns the snapshot as a structure — that is how the Hub’s polling reads it. The line below prints the same thing in the console.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

1 relation

Applies to

How a message gets into the engineMeasures the submission path by which messages arrive at the node. inference

Referenced from

Exposing metrics to a collectorThe metric by which the mechanism is visible. § 11.22

How to check on the node
The metric is viewed together with the neighboring ones — on its own any number means little:
pmta show status
pmta show queues --sort=rcpt --maxitems=20
The first prints all node metrics at once. The second breaks down by queue what the first gives as one number — and that is usually where you can see which queue made it up.
◇

What else to read

3 articles

◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Connect a sending platform