1. パフォーマンス

EXMディスパッチ プロセスとパフォーマンスのチューニング

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

ディスパッチ プロセスは、EXMがメール キャンペーンをキューに入れ、生成し、送信するために使用する一連のパイプラインとプロセッサです。 DispatchNewsletterパイプラインとSend Emailパイプライン は、ディスパッチ プロセスの主要なコンポーネントです。

ディスパッチ プロセスのパフォーマンスを向上させるには、このトピックで説明する推奨事項に従ってください。

サーバーの役割

環境には、0個を含むさまざまな数の専用電子メール ディスパッチ サーバー ロール (DDSロール) を含めることができますが、常に1つのプライマリ コンテンツ管理サーバー (プライマリCM) のみ存在します。

  • DDSロールは、Content Management (CM) ロールの拡張です。サーバーは、CMロールのみ、またはCMロールとDDSロールの両方として機能できますが、DDSロールとして単独で機能することはできません。EXM UIはDDSロールでは使用できません。

  • プライマリCMロールは、EXM UIを使用できる唯一のCMロールです。プライマリCMは、ディスパッチ プロセスの初期化、キューイング、開始など、ディスパッチ プロセスを管理します。デフォルトでは、プライマリCMはディスパッチ サーバとしても機能します。

    1つ以上のDDSロールを持つセットアップでは、プライマリCMロールを実際のディスパッチに参加せず、タスクの調整のみを行うように設定して、コンテンツのオーサリングが遅くならないようにすることができます。

DispatchNewsletterパイプライン

DispatchNewsletterパイプラインは、メールキャンペーンのキューイング、生成、送信を制御します。フルDispatchNewsletterパイプラインは、プライマリCMでのみ実行されます。パイプラインの簡略化されたバージョンは、DDSロールで実行されます。SendEmailパイプラインは、常にDDSロールで実行されます。パイプラインは、サーバー上のSendMessageパイプライン プロセッサを無効にしない限り、プライマリCMロールでも実行できます。

DispatchNewsletterパイプラインでは、次のパイプラインプロセッサがディスパッチプロセスのパフォーマンスに影響を与えます。

  • WaitForDispatchToFinish

  • QueueMessage

  • SendMessage

WaitForDispatchToFinish(プライマリCMロールのディスパッチを使用不可にする)

WaitForDispatchToFinishパイプラインプロセッサは、電子メールキャンペーンのディスパッチが完了するのを待っている間に、各DDSロールを照会します。WaitForDispatchToFinishパイプライン プロセッサは、少なくとも1つのDDSロールが構成されている場合は有効にできます。

このプロセッサを有効にすると、プライマリCMロールのSendMessageパイプライン プロセッサを無効にできます。このようにして、プライマリCMロールは電子メール メッセージを送信しなくなり、代わりにDDSロールが負荷を処理します。

キューメッセージ

QueueMessageパイプラインプロセッサは、セグメンテーションエンジンを使用して、電子メールキャンペーンに含まれる受信者を決定します。

メモ

これは、通常のメールキャンペーンにのみ適用されます。 QueueMessageパイプラインは、自動化されたメールキャンペーンをスキップします。

メール キャンペーンに含める受信者または除外する受信者は、次のアプローチによって決定されます。

含まれる受信者

除外された受信者

メール キャンペーンに含まれるリストにある連絡先。

  • 除外リストとグローバルオプトアウトリストにあるコンタクト。

  • ConsentInformationファセットにDoNotMarketまたはConsentRevokedの設定が設定されているコンタクト。

  • EmailAddressListファセットのコンタクトの優先EメールアドレスのBounceCount設定の値が、マネージャールートのUndelivered Maximum設定を超えているコンタクト。

手記

含める受信者と除外する受信者を決定する方法をオーバーライドするには、Sitecore.EmailCampaign.Cm.Dispatch.IDispatchManagerインターフェイスの独自の実装を作成します。

QueueMessageパイプライン プロセッサは、含まれる各受信者の連絡先識別子をexm.masterデータベースのDispatchQueueテーブルに追加します。次に、Sitecore.EmailExperience.ContentManagement.configファイルの次の設定に従って、複数のスレッドのキューに問い合わせをバッチで追加します。デフォルトでは、4つのスレッドが並行して実行され、各スレッドは一度に300の連絡先をキューに入れます。

  • DispatchEnqueueBatchSize – 既定値は300。

  • DispatchEnqueueThreadsNumber – 既定値4。

これらの値を調整してパフォーマンスを向上させることができます (たとえば、各1000人の連絡先をキューに入れるスレッドを10個持つことができます)。これは、次の場合に推奨されます。

  • メール キャンペーンを多数の連絡先 (1,000,000人以上など) に配信します。

  • 待ち行列には時間がかかることを体験してください。

  • SQLサーバーの負荷に問題があります。

メッセージ送信

SendMessageパイプライン プロセッサは、電子メール メッセージの実際のディスパッチを開始します。次のインスタンスが開始されます。

  • メッセージタスクランナー

  • ディスパッチタスク

メッセージタスクランナー

メッセージタスクランナーは、Sitecore.EmailCampaign.Cm.Dispatch.IMessageTaskRunnerインターフェースのインスタンスです。デフォルトの実装はSitecore.EmailCampaign.Cm.Dispatch.MessageTaskRunnerです。

メッセージ タスク ランナーは、Sitecore.EmailExperience.ContentManagement.configファイルで指定された次の設定に従って、複数のディスパッチ タスクを開始します。

  • NumberThreads – 既定値は10です。

  • MaxGenerationThreads – デフォルト値は、現在のマシン上のプロセッサの数 * 2です。

MaxGenerationThreads設定では、同時に実行できるディスパッチ タスクの数が制限されます。例えば：

  • NumberThreadsとMaxGenerationThreadsの値が両方とも16に設定されている場合、16個のディスパッチ タスクが同時に処理されます。

  • MaxGenerationThreadsを8に、NumberThreadsを16に設定すると、ディスパッチ タスクのうち8つだけが同時に処理され、他の8つのタスクはブロックされて処理されます。

メールキャンペーンの発送速度を向上させるために、NumberThreadsとMaxGenerationThreadsの値を増やすことができます。ただし、これによりCPUの負荷が増加します。

ディスパッチタスク

ディスパッチ タスクは、Sitecore.EmailCampaign.Cm.Dispatch.IMessageTaskインターフェイスのインスタンスです。デフォルトの実装はSitecore.EmailCampaign.Cm.Dispatch.DispatchTaskです。

ディスパッチ タスクは、Sitecore.EmailExperience.ContentManagement.configファイルのEXM.DispatchBatchSize設定に従って、コンタクトをバッチで処理します。デフォルトのバッチ・サイズは100です。

バッチごとに、次のタスクが実行されます。

  • ディスパッチ タスクは、exm.masterテーブルのDispatchQueueテーブルから100個の連絡先識別子を取得します。

  • これらの100個のコンタクトIDは、xConnectから100個のコンタクト (メール アドレスなどの関連ファセットを含む) をロードするために使用されます。

  • 連絡先ごとに、SendEmailパイプラインが実行されます。

  • パイプラインが100件の連絡先を処理したら、次のようになります。

    • Email Sentイベントとのインタラクションは、メールキャンペーンが正常に送信された連絡先ごとに作成されます。これは1つのバッチでxConnectに送信されます。

    • Eメール・アドレスを変更したすべての連絡先のリストを含むメッセージが、EmailAddressHistoryBusメッセージング・バスに送信されます。これにより、EmailAddressHistoryファセットが更新されます。

EXM.DispatchBatchSize設定のデフォルト値を増減すると、ディスパッチのパフォーマンスに大きな影響を与える可能性があります。設定値を大きくすると、EXMがxConnectに対して行うリクエストの数は減少しますが、ある時点でリターンが減少する可能性があります。これは、EXMがコンタクトをロードし、インタラクションを作成し、ファセットを更新する速度に影響します。

SendEmailパイプライン

SendEmailパイプラインは、メール キャンペーンに含まれるすべての受信者に対して実行されます。

FillEmailパイプライン プロセッサとSendEmailパイプライン プロセッサは、それぞれ電子メール ヘッダーとコンテンツを設定し、SMTPディスパッチを実行します。

Sleepパイプライン プロセッサはスロットルとして機能し、電子メールが送信されるたびに遅延を挿入します。デフォルトでは、この遅延は50ミリ秒に設定されています。

パフォーマンスを向上させるには、この遅延を減らすか、Sleepパイプライン プロセッサを完全に削除します。ただし、これによりCPU負荷が増加します。

処理とレポート

EXMレポート プロセスは、Sitecore Processingロールに依存しています。メール メッセージをディスパッチすると、Processingロールはページ イベントとゴールをコンタクト インタラクションとして記録し、それらをxConnectの処理プールに送信します。そのため、メール キャンペーンを多数のコンタクトに送信すると、EXMがすべての情報をxConnectにレポートするのに時間がかかり、分析レポートが遅れる可能性があります。

Sitecore Processingロールを分離して、処理パフォーマンスを向上させ、プライマリCMのワークロードを削減し、Sitecore Processingロールをスケールアウトする機会を提供できます。

一般的なパフォーマンスの最適化

一般的なディスパッチのパフォーマンスを向上させるには、次の領域の最適化を検討してください。

  • 電子メール メッセージのサイズ

  • パーソナライゼーションの使用

  • 連絡先の数

  • ディスパッチサーバーの数

  • サプレッションリスト

手記

EXMモジュールが効率的に動作することを確認し、さらにパフォーマンス チューニングが必要かどうかを判断するために、EXMパフォーマンス測定ツールを実行できます。

電子メール メッセージのサイズ

電子メール メッセージのサイズは、ディスパッチのパフォーマンスに大きく影響します。ディスパッチ中に転送する必要のある大量のデータが電子メール メッセージに含まれている場合、1秒あたりに送信される電子メール メッセージの数は少なくなります。

電子メール メッセージのサイズは、メッセージでレンダリングする必要があるコンテンツの量によって決まります。したがって、ディスパッチのパフォーマンスを向上させるために、メッセージに余分なテキストや画像が含まれていないことを確認できます。さらに、ManagerルートのEmbed Images設定が無効になっていることを確認します。電子メール メッセージに埋め込まれた画像は、多くの場合、電子メール メッセージのサイズを大幅に増大させます。

パーソナライゼーションの使用

メール メッセージでルールベースのパーソナライゼーションまたはパーソナライゼーションの背後にあるカスタム コードを使用する場合、EXMはすべての受信者にメール メッセージをレンダリングします。これは、パフォーマンスに重大な悪影響を及ぼします。

トークンの置換のみを使用する場合は、メール キャンペーンのDeliveryタブでパーソナライゼーションを無効にしてください。これにより、出力はEmailCampaign.MessageBodyCacheに保存されるため、EXMは、メール キャンペーンのバリアントや言語バージョンごとに、すべてのディスパッチ タスク スレッドに対してメール キャンペーンを1回だけレンダリングします。EXMでキャッシュ サイズを指定できます。MessageBodyMaxCacheSize設定を使用します。

連絡先の数

メールキャンペーンに追加する受信者の数も、ディスパッチのパフォーマンスに影響します。メール キャンペーンに追加する受信者が多いほど、EXMがメール キャンペーンを送信するのにかかる時間が長くなります。

メール キャンペーンを多くの受信者に送信し、高いディスパッチ パフォーマンスを維持できるようにするには、ディスパッチ サーバーを追加し、より多くのリソース (CPUなど) を使用できるようにし、高品質の連絡先データを確実に維持できます。

EXMはリスト マネージャーを使用して、メール キャンペーンの受信者リストを管理します。EXMが連絡先リストから連絡先の登録を解除する場合でも、リストを同時にクリーンアップすることが重要です。例えば：

  • 外部データソースから連絡先を同期する場合は、以前に登録解除した連絡先を追加しないようにする必要があります。

  • セグメント化されたリストを使用する場合は、セグメンテーション条件が正しいこと、およびファセットが適切に更新されていることを確認する必要があります。

ディスパッチサーバーの数

専用のメール発送サーバーを追加する必要はありませんが、発送パフォーマンスが悪いという問題がある場合は、追加することをお勧めします。

専用のディスパッチサーバーを追加する場合:

  • 負荷はコンテンツオーサリング環境から取り除かれ、編集者は電子メールキャンペーンのディスパッチプロセス中にパフォーマンスの低下の影響を受けません。

  • メッセージの生成とディスパッチのプロセスが大幅に改善されました。

手記

専用のメールディスパッチサーバーは、必要な数だけ追加できます。 「専用Eメール・ディスパッチ・サーバー 」トピックでは、1つ以上の専用ディスパッチ・サーバーのインストールが推奨される場合の概要について説明します。

サプレッションリスト

Email Cloudプロバイダーを使用する場合、ローカルにキャッシュされたサプレッションリストは、Email Cloudプロバイダーが抑制しているEメールアドレスにEメールを送信しないように、含まれる各連絡先をチェックします。これにより、帯域幅が節約され、各連絡先のデータベース検索が追加で犠牲になる抑制された電子メールに対して課金されることがなくなります。

このチェックを無効にするには、Sitecore.EmailExperience.ContentManagement.configファイルでEXM.CheckSuppressionList値をfalseに設定します。

EXMサプレッション リストの詳細については 、「サプレッション リストの管理」を参照してください。

この記事を改善するための提案がある場合は、 お知らせください!