一次活动提交请求的速度可能快于投递路径处理消息的速度。规划发送需要对每个阶段进行容量估算。
API 请求速率限制与吞吐量有何不同？
API 速率限制控制的是请求。投递吞吐量控制的是后续阶段处理消息或分段的速度。
当 Bird 以 429 拒绝请求时，请遵循响应请求头和速率限制指南。立即重试可能导致同样的拒绝。
提交成功的含义有所不同。202 确认的是接受，而计费、网络提交和投递发生在之后。请通过这些后续结果跟踪消息标识符。
当提交量超过发送速率时，Twilio 会将消息加入队列；超出容量时会报告队列溢出错误：“Customers sending large volumes of messages may encounter errors such as Queue Overflow”。
哪些因素决定了可用速率？
有效速率取决于发送方、目的地、注册状态、服务商配置和适用的账户限制。
短码和长码在同一目的地可以有不同的容量。注册状态会影响发送方可承载的流量。在规划发送量之前，请查看发送方选择和目的地要求。
公布的最大值是容量上限，不是投递承诺。在将其应用于活动之前，请确认计量单位、适用范围和前提条件。
如何估算发送时间？
用工作量除以采用相同单位计量的速率。一个分段是单条网络消息承载的文本。较长的文本需要多个分段。
以一条限速为每秒 100 个分段的示例路由为例，6,000 条单分段消息至少需要 60 秒的容量。如果每条消息需要两个分段，同样的工作量至少需要 120 秒。
上述计算假设持续使用标称容量。其他流量、暂停、重试和下游条件都可能延长所需时间。这些计算也不预测每位接收者何时阅读或收到消息。
使用分段计算器检查个性化内容。较长的姓名或表情符号可能改变计费文本量。
为什么请求成功了消息却延迟了？
排队、下游处理、网络状况和接收方可用性都可能导致接受与投递之间出现延迟。
比较接受、提交和报告的投递时间。按发送方和目的地检查错误。缺少回执本身并不能确定原因。
SMS 消息中心可以在手机不可用时保留消息。什么是 SMSC 解释了该阶段。SMS 分析介绍了如何在 Bird 中调查结果。
不要仅仅因为投递回执迟到就重新提交已接受的消息。这可能产生重复短信，而不能解决延迟问题。
如何为更大规模的活动做准备？
选择适合流量的发送方和容量计划，然后在扩大规模之前先进行小范围测试。
与服务商讨论目标国家、分段量和所需的发布时间窗口。在进行更大规模的发送之前，可能需要先完成注册和发送方准备。
将流量分散到多个号码以规避运营商限制的做法称为 snowshoeing。CTIA 准则对此进行了说明。
- 按目的地统计渲染后的分段数。
- 确认每条发送路径的速率、计量单位和适用范围。
- 为处理和下游波动预留时间。
- 先发送一个小批量，检查结果，然后逐步扩大。
简而言之
API 容量与投递容量衡量的是不同阶段。
请求成功并不意味着每条消息都能立即发往网络。
检查限制背后的计量单位。
请求、消息和分段会产生不同的容量计算结果。
投递延迟有多种可能原因。
在将延迟归因于吞吐量之前，先检查排队、错误和投递事件。
为发送方和目的地规划容量。
账户限制、注册要求和运营商规则也可能制约发送路径。