キャンペーン：バッチ配信のスループットが予想よりも低い
バッチメール配信は、送信インフラストラクチャに機能する欠陥がない場合でも、予想よりも遅く送信される可能性があります。 このパターンでは、配信はブロックされませんが、メールコンテンツが使用可能な送信容量に対して大きすぎて、期待されるスループットで処理できないため、達成済みの送信率が低下します。
説明 description
配信は、予想される時間単位の送信目標に対してパフォーマンスが低いと報告されました。 予想送信率は1時間あたり2,000万通のメールでした。 このテストでは、1時間で最大1,300万通の電子メールが配信されることが示されました。
最初のレビューでは、プラットフォームの永続的な障害は表示されませんでした。
配信の準備がログに記録されました：
警告：配信コンテンツのサイズが200.0 kB （227.2 kB）を超えています。
解決策 resolution
フォローアップの分析では、主な要因はメールコンテンツのサイズであることが示され、ベストプラクティスのガイダンスを大幅に上回りました。
フォローアップテストでコンテンツサイズを削減すると、スループットが大幅に向上しました。 これにより、この問題は、一般的なプラットフォームの停止ではなく、主にメッセージのサイズと処理コストに関連していることが確認されました。
電子メールのサイズが送信速度に影響を与える理由？
メールサイズは、スループットに直接影響します。すべてのメッセージは次のようにする必要があるからです。
- パーソナライズされたコンテンツを，
- パーソナライゼーションとトラッキング用に処理され，
- 送信に備え、
- 署名済みで配達用にパッケージ化されているので，
- ネットワーク経由で転送されます。
HTMLのペイロードが増加するにつれ、これらの各ステップの費用が高くなります。
大量のバッチ送信では、そのコストが数百万のメッセージに増大します。 システムが正常な状態を維持しても、大きなメッセージは送信層でより多くのCPUとネットワーク帯域幅を消費します。 リソースが飽和状態になった場合でも、システムは正常に送信できますが、1時間あたりのメッセージ数は減少します。
なぜこれが起こるのか？
大きなメールの配信が遅くなる最も一般的な理由は次のとおりです。
- 受信者ごとに送信するバイト数を増やす必要があります。 より大きなメッセージには、より多くのアウトバウンドネットワーク転送が必要です。 大規模な場合、これだけでも制限の要因になる可能性があります。
- メッセージごとに処理が必要です。 HTMLのボディを大きくすると、コンテンツの組み立て、パーソナライゼーション、トラッキングリンクの処理、メッセージのパッケージ化に必要な作業が増えます。
- 送信層は、より早くリソース制限に達します。 CPUまたはアウトバウンド帯域幅が十分に活用されている場合、スループットの停滞が発生します。 これは必ずしも誤動作を示すものではなく、現在のメッセージサイズに対してインフラストラクチャがフル容量で動作していることを意味します。
- テンプレートデザインでサイズが予期せず膨らむ可能性があります。 過度なマークアップや過度に複雑なパーソナライゼーションは、オーサリング時に表示されるサイズをはるかに超えて、レンダリングされたメッセージのサイズを増加させる可能性があります。
各メッセージあたりのサイズが200 kBを超え、各2つのサーバーコンテナを備えた2つのMID ソーシングサーバーを使用すると、送信中に次のことが確認されました。
CPU 4つすべてで100%維持（ユーザースペース – メッセージアセンブリ / DKIM）
ホストあたり210 MB/秒のTXをネットワーク化（4つのコンテナ全体で850 MB/秒）
メモリ 35%使用済み、スワップ 0、iowait 0%
速度17.6M/hを達成
iowait 0とメモリの31%は、何も飢えていないか立ち往生していないことを意味します。 CPUが100%の場合、MID層はアクティブなボトルネックであり、完全に使用されます。これは、スループットテストでプッシュされる結果と同じです。 100% CPUが表す唯一の点は、スペアのCPU ヘッドルームがないので、さらなるスループットまたはマージンは、より軽いメールまたはMID コア/コンテナのいずれかから得られることです。
Adobeのベストプラクティスは、35 kB前後の電子メールを保持することです – https://experienceleague.adobe.com/ja/docs/campaign/campaign-v8/send/delivery-best-practices