活动期间队列增长可能有多种原因。应用程序生成邮件的速度可能比其提供商接受邮件的速度快，提供商可能会减慢出站投递速度，或者接收系统可能会推迟特定目的地的发送。将这三个都称为“ Gmail限制”隐藏了瓶颈的位置。
找到第一个延迟阶段
参考： RFC 5321 §4.2.1, RFC 5321 §4.5.4.1.
捕获作业创建、提供商提交、提供商接受和每次交付尝试的时间戳。保留完整的响应文本和发出它的系统。成功的应用程序 API 响应与最终接收服务器接受消息不同。如果提供者未公开某个阶段，请将其标记为不可用，而不是推断确切的时间戳。
SMTP将临时否定答复与永久否定答复区分开来。临时响应并不是全速不断重试的指示；发送系统需要一个队列和适当的重试策略。永久性故障不应被视为无休止的临时积压。 RFC 5321第 4 节和 4.5.4.
检查更改的工作负载
比较目的地组合、独特的消息和尝试。发送多次重试的活动可能会增加尝试计数，而不会代表其他收件人。将营销作业与延迟敏感的事务消息分开，并检查它们是否竞争相同的并发或速率预算。
谷歌建议在监控响应的同时避免突发并逐渐增加流量。将当前的Gmail指南应用于其规定的范围，而不是将其转化为通用的每秒安全邮件限制。本文中的任何公众号都无法证明发送者的身份。 Gmail发件人指南.
进行队列算术
参考： RFC 5321 §4.2.1.
本地综合模型以空队列开始。新作业以每分钟 120 条消息的速度到达，而假设的服务速率为每分钟 80 条，持续 10 分钟。积压的消息每分钟增加 40 条，达到 400 条。如果随后暂停到达并继续保持相同的服务费率，则理想的流失时间为五分钟。
这是队列算术，而不是测量的提供者限制或实时恢复的预测。它故意排除重试、过期和更改服务费率。这些遗漏解释了为什么真正的队列可能需要更长的时间。在计算的同时保留假设，这样容量工作表就不会成为不受支持的服务水平承诺。
保留的确定性响应状态模型在离线状态下重新运行以进行此审核，并保留尝试分类帐。在 UTC 时间 09:00，一项脚本化作业收到“451 4.7.0 临时速率限制；稍后重试”。其状态变为重试待定，受影响的流被标记为减压，并且在 09:30 受控的本地重试收到“250 2.0.0 Accepted”。另一个作业在 09:00 收到“550 5.1.1 No such returned”，并进入永久失败，无需重试；其下一步行动是批准收件人验证。这些完整的回复是发明的本地测试输入。三十分钟是该灯具的重试设置，而不是通用的提供商指令。该代码从响应类派生状态转换，并禁止计划外的第二次尝试。
减轻压力而不失正确性
参考： RFC 5321 §4.5.4.1.
通过批准的调度程序暂停或减少受影响的非必要流。让负责的队列使用其支持的策略重试临时失败。避免创建第二个队列来重新发送同一事务，因为仪表板会延迟。使用稳定的事务标识符来协调不确定的提交结果。
对于紧急消息，仅在验证身份验证和防止重复后才遵循批准的连续性路线。不要通过轮换基础设施来逃避提供商的限制。使用时间戳、响应文本、目标范围、路由标识符和纠正更改的证据进行升级。
当积压和年龄分布在定义的合法工作负载下稳定时，恢复扩展。继续检查最旧的消息：较低的平均延迟可以隐藏一小部分严重逾期的重置或收据。