Campaign: Batch delivery throughput lower than expected
A batch email delivery may send more slowly than expected even when there is no functional defect in the sending infrastructure. In this pattern, the delivery is not blocked, but the achieved send rate drops because the email content is too large for the available sending capacity to process at the expected throughput.
Description description
A delivery was reported as underperforming against its expected hourly send target. The expected sending rate was 20M emails per hour. The tests showed a maximum of ~13M emails delivered in one hour.
Initial review did not show a persistent platform failure.
The delivery preparation logged:
Warning: Size of Delivery Content is over 200.0 kB (227.2 kB).
Resolution resolution
Follow-up analysis showed that the main contributing factor was the size of the email content, which was significantly above best-practice guidance.
When the content size was reduced in follow-up testing, throughput improved materially. This confirmed that the issue was primarily related to message size and processing cost, not a general platform outage.
Why email size impacts send speed?
Email size has a direct effect on throughput because every message must be:
- assembled for the recipient,
- processed for personalization and tracking,
- prepared for transmission,
- signed and packaged for delivery,
- transferred over the network.
As the HTML payload grows, each of those steps becomes more expensive.
In high-volume batch sends, this cost is multiplied across millions of messages. Even if the system remains healthy, larger messages consume more CPU and network bandwidth on the sending tier. Once those resources are saturated, the system can still send successfully, but the messages-per-hour rate declines.
Why this happens?
The most common reasons larger emails slow delivery are:
- More bytes must be transmitted per recipient. Bigger messages require more outbound network transfer. At scale, this alone can become a limiting factor.
- More processing is required per message. Larger HTML bodies increase the work needed for content assembly, personalization, tracking-link handling, and message packaging.
- The sending tier reaches resource limits sooner. When CPU or outbound bandwidth is fully utilized, throughput plateaus. This does not necessarily indicate a malfunction; it can simply mean the infrastructure is operating at full capacity for the current message size.
- Template design can inflate size unexpectedly. Excessive markup or overly complex personalization can increase rendered message size far beyond what is apparent during authoring.
With the size over 200kB per each message and using 2 MID-sourcing servers with 2 server containers each, it was observed that during sending:
CPU 100% sustained on all 4 (user space - message assembly / DKIM)
Network 210 MB/s TX per host ( 850 MB/s across the 4 containers)
Memory 35% used, swap 0, iowait 0%
Achieved speed 17.6M/h
iowait 0 and memory 31% mean nothing is starved or stuck. CPU at 100% means the MID tier is the active bottleneck and is fully used, which is exactly what a throughput test pushes it to. The only thing 100% CPU represents is that there is no spare CPU headroom, so further throughput, or margin, comes from either lighter emails or more MID cores/containers.
Adobe best practice is to keep an email around 35 kB - https://experienceleague.adobe.com/en/docs/campaign/campaign-v8/send/delivery-best-practices