BROKER_TRANSMITTER is recorded when the Service Broker transmission queue is empty and the two internal transmitter threads (the ones that send messages to remote endpoints) wait for work. Two threads waiting simultaneously gives this wait its arithmetic signature: the total grows by roughly two seconds every second while Service Broker is idle.
Every instance carries it, Broker traffic or not.
Is It a Problem?
No; it is a standard benign wait, and its inflated growth rate makes it look scarier than it is in raw rankings. Idle transmitters are the correct state whenever no cross-instance Broker messages need sending; local-only Broker usage (activation within one database) barely touches them either.
Actual transmission trouble is visible in sys.transmission_queue: stuck messages accumulate there with an error description naming the problem (endpoint unreachable, security, routing).
Common Causes
- The instance being up, with the transmitter pair idling.
- Local-only or absent Service Broker workloads leaving the senders unemployed.
What To Do
- Filter it out; our
Get-WaitStatisticsscript excludes it by default. - For message delivery problems, query
sys.transmission_queueper database; itstransmission_statustext is the actual diagnostic. - Nothing to tune at the transmitter level.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered; its 2:1 growth ratio makes it easy to recognise in raw output.
BROKER_TRANSMITTER is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply