Campaign：批量投放吞吐量低于预期
即使发送基础结构中没有功能缺陷，批量电子邮件投放的发送速度也可能比预期慢。 在此模式中，不会阻止投放，但实现的发送率会下降，因为电子邮件内容过大，无法以预期的吞吐量处理可用发送容量。
描述 description
据报告，投放与其预期每小时发送目标相比性能不佳。 预计发送速率为每小时2000万封电子邮件。 测试显示，一小时内最多可发送约1300万封电子邮件。
初始检查未显示永久性平台故障。
投放准备已记录：
警告：投放内容的大小超过200.0 kB (227.2 kB)。
解决方法 resolution
后续分析表明，主要原因是电子邮件内容过大，大大高于最佳做法指导意见。
在后续测试中，当内容大小减小时，吞吐量得到大幅提高。 这证实了该问题主要与报文大小和处理成本有关，而不是与一般平台故障有关。
为什么电子邮件大小影响发送速度？
电子邮件大小直接影响吞吐量，因为每封邮件必须：
- 为收件人组装，
- 已处理以进行个性化和跟踪，
- 准备传输，
- 签了名并打包交货，
- 通过网络传输。
随着HTML有效负载的增大，其中每个步骤的成本都会提高。
在大流量批量发送中，此成本是数百万条报文的乘积。 即使系统保持正常运行，较大的消息也会消耗发送层上更多的CPU和网络带宽。 当这些资源饱和时，系统仍可以成功发送，但每小时消息发送率会下降。
为什么会出现这种情况？
大型电子邮件投放缓慢的最常见原因是：
- 每个收件人必须传输更多的字节。 较大的消息需要更多的出站网络传输。 从规模上看，仅此一项就可能成为一个限制因素。
- 每条消息都需要进行更多处理。 更大的HTML机构可增加内容汇编、个性化、跟踪链接处理和消息打包所需的工作。
- 发送层会更快地达到资源限制。 当CPU或出站带宽得到充分利用时，吞吐量将趋于平稳。 这并不一定表明发生了故障；它只可能意味着基础结构正在以满负荷运行以符合当前报文规模。
- 模板设计可能会意外夸大大小。 过多的标记或过于复杂的个性化可能会增加呈现的消息大小，使其远远超过创作期间显示的内容。
如果每条消息的规模超过200 kB，并且使用2个中间源服务器（每个服务器容器为2个），则在发送过程中会发现：
CPU 100%持续存在于所有4个（用户空间 — 消息汇编/DKIM）
每个主机的网络为210 MB/s TX （在4个容器中为850 MB/s ）
内存使用率为35%，交换率为0，iowait为0%
已实现速度17.6米/小时
iowait 0和31%的内存意味着没有东西被饿死或卡住。 CPU达到100%意味着MID层是活动瓶颈，并且已得到充分使用，这正是吞吐量测试推动它达到的目标。 CPU 100%代表的唯一一点就是CPU没有多余的空间，因此更高的吞吐量或利润率来自更轻的电子邮件或更多的MID核心/容器。
Adobe的最佳做法是将电子邮件保留在35千b左右 — https://experienceleague.adobe.com/zh-hans/docs/campaign/campaign-v8/send/delivery-best-practices