Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.44

track-outbound-perf-stats

Global

Whether to measure the duration of an outbound SMTP conversation
in the configuration this is a linetrack-outbound-perf-stats falseinside the block Global
How long the conversation with the receiver takes

The line enables counting the duration of an outbound SMTP transaction — from MAIL FROM to the end of DATA in the conversation with the receiver. The default is false.

🔴 Like its pair, it is useful only together with <prometheus-listener>: the value goes only into the pmta_smtp_request_duration_seconds metric with the direction=”out” label.

This is not the message delivery time. It is the duration of one conversation: a message may have sat in the queue for a day while the transaction took half a second. The delay before the first attempt is the job of another line — track-time-first-attempt.

The practical point is telling your own trouble from someone else’s. Growing delay in outbound transactions with inbound unchanged means receivers are slow to respond, not that the node is overloaded. These call for different cures.

The main trap is taking this value for delivery time. The conversation is fast, but the message took a day — a normal picture with backoff mode or limits. Delivery time is made up of waiting in the queue and the conversation, and the former is not counted here.
What the Hub does. It does not write it and does not configure the metrics listener.

🔎 The fleet dashboard answers an indirectly similar question from accounting — by the share of transient errors and the queue depth. But the conversation duration itself is something we do not have, and it is what tells “the receiver is slow” from “the node cannot cope.”

Recommended values

Enabled together with the acceptance half:

Value When
false (default) there is no metrics listener
true the listener is configured, and the “acceptance — sending” pair is needed

Separately the values are almost useless: their value is in the comparison.

The false default, the definition of a transaction and the caveat “useful only with the metrics listener” come from the manual (§ 3.3.1.44, § 11.22). The “your own trouble versus someone else’s” distinction is ours.
Example configuration
# a pair of values that are compared with each other
track-inbound-perf-stats true
track-outbound-perf-stats true
<prometheus-listener 0/0:9090>
</prometheus-listener>
The comparison is the point: outbound grows while inbound stays flat — the receivers are slow; both grow — it is the node.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Reading the value as message delivery time

our experience

What it costsOnly the conversation is counted. Waiting in the queue — which is usually most of the delivery time — is not included at all.
How to spot itThe metric shows fractions of a second, while messages take hours.
How to do it rightLook at track-time-first-attempt — it is about the delay before the first attempt.
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.
Reference data
Syntax
track-outbound-perf-stats <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.44
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line is written at the root of the file, in the Global section, and applies to all outbound transactions. The metric cannot be split by receiver — the label distinguishes only the direction.
⇄

Related directives

2 relations

Does not work without

Serving node metrics in a standard formatThe only place this value goes to; without the block, counting goes into the void. § 3.3.1.44

Works together with

track-inbound-perf-statsGlobalThe other half of the same metric: one about acceptance, the other about sending. § 3.3.1.43

Referenced from

time-first-attempt-domains-file<prometheus-listener>A neighboring value of the same listener — the sending delay, with no breakdown by receiver. § 3.3.1.44

How to check on the node
Check it at the metrics listener:
curl -s http://NODE:9090/metrics | grep pmta_smtp_request_duration_seconds
Lines with the direction=”out” label mean the counting works. Next to them there should be the 0.5, 0.9, 0.95 and 0.99 quantiles — it is a summary, not a single number.
◇

What else to read

3 articles

◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability
Neighboring settings of the block Global:http-mgmt-porttrack-inbound-perf-statsdummy-smtp-update-statshttp-default-max-itemshttp-default-sort-orderAll 108 directives of the block →