---
title: "EXMディスパッチプロセスとパフォーマンスチューニング"
slug: "the-exm-dispatch-process-and-performance-tuning"
abstract: "配車プロセスの流れを理解し、パフォーマンスを向上させる方法を考えましょう。"
---
# EXMディスパッチプロセスとパフォーマンスチューニング

ディスパッチプロセスは、EXMがメールキャンペーンのキューイング、生成、送信に使用する一連のパイプラインとプロセッサです。 [DispatchNewsletterとSend Emailパイプライン](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/the-exm-pipelines.html "The EXM pipelines") はディスパッチプロセスの主な構成要素です。

このトピックで示された推奨事項に従うことで、配車プロセスのパフォーマンスを向上させることができるかもしれません。

## サーバーの役割

環境には専用メールディスパッチサーバー(DDSロール)の役割がさまざまに存在しますが、常に1台のプライマリContent Managementサーバー(プライマリCM)のみが存在します。

-   DDSの役割はContent Management (CM)の役割の拡張です。サーバーはCM役割のみまたはCM役割とDDS役割の両方として機能できますが、DDS役割だけとして機能することはできません。EXM UIはDDSの役割には使用できません。
    
-   プライマリCMロールはEXM UIを使用できる唯一のCMロールです。プライマリCMはディスパッチプロセスを管理し、例えば初期化、キューイング、ディスパッチプロセスの開始を行います。デフォルトでは、プライマリCMはディスパッチサーバーとしても機能します。
    
    1つ以上のDDSロールが存在する場合、プライマリCMの役割は実際のディスパッチに参加せず、コンテンツ作成の遅延を避けるためにタスクの調整のみに設定できます。
    

## ディスパッチニュースレターのパイプライン

DispatchNewsletterのパイプラインは、メールキャンペーンのキュー作成、生成、送信を制御します。DispatchNewsletterのフルパイプラインはプライマリCM上でのみ動作します。パイプラインの簡略版はDDSロール上で動作します。SendEmailパイプラインは常にDDSロール上で動作します。サーバーのSendMessageパイプラインプロセッサを無効化しない限り、パイプラインはプライマリCMロールでも動作可能です。

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

-   WaitForDispatchToFinish
-   QueueMessage
-   SendMessage

### WaitForDispatchToFinish(プライマリCMロールのディスパッチを無効にする)

WaitForDispatchToFinishパイプラインプロセッサは、メールキャンペーンのディスパッチ完了を待つ間、各DDSロールにクエリを行います。少なくとも1つのDDSロールを設定していれば、WaitForDispatchToFinishパイプラインプロセッサを有効にすることができます。

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

### キューメッセージ

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

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

メールキャンペーンに含まれるか除外される受信者は以下の方法で決まります。

受賞者一覧

除外受賞者

メールキャンペーンの含まれている連絡先リスト。

-   除外リストやグローバルオプトアウトリストにある連絡先です。
-   ConsentInformationの側面で DoNotMarket または ConsentRevoked 設定が設定されている連絡先です。
-   EmailAddressListの面で、連絡先の希望メールアドレスの BounceCount 設定がマネージャールートの未配達最大値(Undelivered Maximum)を上回っている連絡先です。

> !注Sitecore.EmailCampaign.Cm.Dispatch.IDispatchManagerインターフェースの実装を作成することで、含まれる受信者と除外される受信者の決定方法を上書きできます。

QueueMessageパイプラインプロセッサは、含まれる各受信者の [連絡先識別子](https://doc.sitecore.com/xp/en/developers/100/sitecore-experience-platform/contact-identifiers.html) をexm.masterデータベースのDispatchQueueテーブルに追加します。その後、Sitecore内の以下の設定に従って複数のスレッドやバッチでキューに連絡先を追加します。EmailExperience.ContentManagement.configファイル。デフォルトでは、4つのスレッドが並列に動作し、各スレッドは同時に300件の連絡先をキューイングします:

-   DispatchEnqueueBatchSize – デフォルト値300。
-   DispatchEnqueueThreadsNumber – デフォルト値4.

これらの値を調整してパフォーマンスを向上させることも可能で、例えば10スレッドごとに1000件の連絡先をキューにするなどです。これは以下の場合に推奨されます:

-   例えば、100万人以上の多くの連絡先にメールキャンペーンを発送しましょう。
-   キュー待ちに時間がかかることを経験してください。
-   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のEXM.DispatchBatchSize設定に従って、連絡先をバッチごとに処理します。EmailExperience.ContentManagement.configファイル。デフォルトのバッチサイズは100です。

各バッチごとに、以下の作業が行われます:

-   ディスパッチタスクはexm.masterテーブルのDispatchQueueテーブルから100件の連絡先識別子を取得します。
-   これらの100件の連絡先識別子を使って、xConnectから100件の連絡先を読み込み、メールアドレスなどの関連要素も含まれます。
-   各連絡先ごとにSendEmailパイプラインが実行されます。
-   パイプラインが100件の接触を処理した後:
    -   メールキャンペーンが成功裏に送信された各連絡先ごとに、Email Sendedイベントとのやり取りが作成されます。これはxConnectに一括で送信されます。
    -   メールアドレスを変更したすべての連絡先のリストを含むメッセージがEmailAddressHistoryBusメッセージバスに提出されます。これによりEmailAddressHistoryの側面が更新されます。

EXM.DispatchBatchSize設定のデフォルト値を上げたり下げたりすると、ディスパッチのパフォーマンスに大きな影響を与えることがあります。設定値を上げると、EXMがxConnectに送るリクエスト数は減りますが、ある時点で収益逓減が発生することがあります。これにより、EXMが連絡先の読み込み速度、インタラクションの作成、ファセットの更新速度に影響します。

## SendEmailパイプライン

[SendEmailパイプライン](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/the-exm-pipelines.html "The EXM pipelines")は、メールキャンペーンに含まれるすべての受信者に対して実行されます。

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

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

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

## 処理と報告

EXMの報告プロセスはSitecore処理ロールに依存しています。メールを送信する際、処理ロールはページのイベントや目標を連絡先のやり取りとして記録し、[xConnect](https://doc.sitecore.com/xp/en/developers/100/sitecore-experience-platform/service-plugins.html)の処理プールに送信します。したがって、多数の連絡先にメールキャンペーンを送信すると、EXMがすべての情報をxConnectに報告するのに時間がかかり、分析レポートが遅れる可能性があります。

Sitecore Processingの役割を分離することで、処理性能を向上させ、プライマリCMの負荷を軽減し、Sitecore Processingの役割をスケールアウトさせる機会を提供できます。

## 一般的な性能最適化

一般的な派遣性能を向上させるために、以下の部分の最適化を検討してください:

-   メールメッセージのサイズ
-   パーソナライズの利用
-   接触数
-   ディスパッチサーバーの数
-   抑制リスト

> !注EXMモジュールが効率的に動作することを確実にし、さらなる性能調整が必要かどうか判断するために、[EXMパフォーマンス測定ツール](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/performance-tuning-and-the-exm-performance-measurement-tool.html "Performance tuning and the EXM performance measurement tool")を実行することができます。

### メールメッセージのサイズ

メールメッセージのサイズはディスパッチのパフォーマンスに大きな影響を与えます。メールに送信中に転送しなければならない多くのデータが含まれている場合、1秒あたり送信されるメール数は減ります。

メールのメッセージのサイズは、そのメッセージに表示しなければならないコンテンツの量によって決まります。したがって、ディスパッチ性能を向上させるために、メッセージ内に余計なテキストや画像がないことを確認してください。さらに、[マネージャー](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/the-manager-root-settings.html "The manager root settings") ルートの「埋め込み画像」設定を無効にしてください。メールメッセージに埋め込みた画像は、メールのサイズを大幅に大きくすることがよくあります。

### パーソナライズの利用

メールにルールベースのパーソナライズやパーソナライズの背後にあるカスタムコードを使った場合、EXMはすべての受信者に対してメールをレンダリングします。これはパフォーマンスに大きな悪影響を及ぼします。

トークン置換のみを使う場合は、メールキャンペーンの**「配信**」タブで[パーソナライズを無効](urn:resource:component:46339)にしてください。これにより、EXMメールキャンペーンのバリアントや言語バージョンごとに各ディスパッチタスクスレッドごとに1回だけメールキャンペーンをレンダリングします。なぜなら、出力はEmailCampaign.MessageBodyCacheに保存されているからです。キャッシュサイズはEXMで指定できます。Sitecore内のMessageBodyMaxCacheSize設定。EmailExperience.Core.configファイル。

### 接触数

メールキャンペーンに追加する受信者の数も、発送のパフォーマンスに影響を与えます。メールキャンペーンに追加する受信者が多いほど、EXMがメールキャンペーンを送信するまでに時間がかかります。

メールキャンペーンを多くの受信者に送りつつ高いディスパッチパフォーマンスを維持するために、追加のディスパッチサーバーを追加し、より多くのリソース(例えばCPU)を活用し、高品質な連絡先データを維持することができます。

EXMはメールキャンペーン内の受信者リストを管理するためにList Managerを使用します。EXMは連絡先リストからの連絡先の購読解除を行いますが、リストを同時にグルーミングすることが重要です。例えば:

-   外部データソースからの連絡先を同期する場合は、以前に購読解除した連絡先を追加しないように注意してください。
-   セグメントリストを使用する場合は、セグメンテーション条件が正しく、ファセットが適切に更新されていることを確認してください。

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

専用のメールディスパッチサーバーを追加する必要はありませんが、ディスパッチ性能が悪い場合は追加したほうがよいでしょう。

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

-   コンテンツオーサリング環境の負担が軽減され、メールキャンペーンの発送プロセスにおけるパフォーマンスの低下に影響を受けません。
-   メッセージ生成およびディスパッチプロセスが大幅に改善されました。

> !注必要なだけ専用のメールディスパッチサーバーを追加できます。 [「専用メールディスパッチサーバー](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/using-dedicated-email-dispatch-servers.html "Using dedicated email dispatch servers") 」のトピックでは、1つ以上の専用ディスパッチサーバーを設置することが推奨される時期の概要が示されています。

### 抑制リスト

Email Cloudプロバイダーを利用する場合、ローカルキャッシュされた抑制リストが含まれる各連絡先をチェックし、Email Cloudプロバイダーが抑制するメールアドレスへのメール送信を避けます。これにより帯域幅を節約し、抑制されるメールに対して料金がかかることなく、各連絡先ごとに追加のデータベース検索が必要になります。

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

EXM抑制リストの詳細については、「 [抑制リストの管理](https://doc.sitecore.com/xp/ja/developers/exm/100/email-experience-manager/managing-the-suppression-list.html "Managing the suppression list")」を参照してください。