この記事では、慢性問題を解決し、Adobe Campaign Classic プラットフォームのパフォーマンスを改善する方法について説明する。

環境

Adobe Campaign Classic (V6/V7) 製品インスタンス。

ワークフロー

次のリストに、ワークフローのパフォーマンスに関するベストプラクティスを含む。このページに、一般的なワークフロー実行とベストプラクティスについての詳細を学習する。

ワークフローの実行

  • ワークフローが完了するまで、データベースに一時テーブルを維持しないようにワークフローを「一時停止」状態にしないでください。
    ワークフローが失敗して、またはシステムによって一時停止されたときに、ワークフロー性能によってワークフロー監督者を配分して警告を送信する。
  • 未使用のワークフローを停止する。引き続き実行するワークフローは、データベースへの接続を維持し続ける。
  • ごくまれに、ワークフローの無条件停止を使用する必要があります。ワークフローによって生成されてデータベースと接続するクリーン終止を実行しないことで、パフォーマンスをインパクトするので、このアクションを定期的に使用しないでください。
  • 実稼働環境ではなく、開発環境またはステージング環境ですべてのテストを実行する。実稼動環境でテストを実行した場合、パフォーマンスは保証できません。
  • 全体的なシステムのパフォーマンスを妨害し、データベースにブロックを作成するため、15分おきに実行するようにワークフローをスケジュールしないことがベストプラクティスである。
  • すべてのワークフローのエンドアクティビティを使用する。これにより、Adobe Campaign はワークフロー内の計算に使用される一時的なスペースを解放することができる。
  • ワークフローを構築する場合、ブランチごとに1つだけのスケジューラアクティビティを使用する。ワークフローの同じブランチに複数のスケジューラがある場合(相互にリンクされている)、実行されるタスク数が倍増し、データベースを大幅にオーバーロードする。このルールはまた、スケジュールと履歴タブですべてのアクティビティに適用することができる。

ワークフローの一時的なテーブルとログ

  • 生産環境でワークフロー性能に「中期業績結果を保持する」オプションを使用しないでください。
    このオプションは結果分析に用いられ、テスト目的のためだけに設計されたので、開発環境またはステージング環境のみに使用される。
  • ワークフロー内でフローを使用してアクティビティを無効にしないでください。これにより、スレッドが開かれ、大量のスペースを消耗する一時的なテーブルが発生する。ワークフローでは、「有効にしない」または「有効にするが実行しない」状態でアクティビティを保持しないでください。
  • ワークフロープロパティの実行タブに使用可能で、ジャーナルにログ SQL クエリーオプションは、それぞれ異なるアクティビティのツールによって生成されたすべての SQL クエリーをログする。これはプラットフォームによって実際に実行された内容を確認するよい方法である。ただし、このオプションは開発中に一時的に使用され、製品ではアクティブ化されない。
  • 不要になった場合は、ログをクリアする。ワークフロー履歴は自動的にはクリアされない:すべてのメッセージはデフォルトで保存される。 フィル> アクションメニューを通して、またはリストの上にあるツールバーのアクションボタンをクリックして、履歴をクリアすることができる。履歴をクリアすることを選択する

配信

以下のリストには、配信のパフォーマンスに関するベストプラクティスが含まれている。このドキュメントこのドキュメントをフォローして、もっと配信のベストプラクティスと監視を学習する。

  • インスタンス上で配信を失敗状態のままにしないでください。失敗状態のままだと、一時テーブルが保持され、パフォーマンスに影響が及びます。
  • 不要になった配信を削除してください。
  • 過去 12 ヶ月間にわたって非アクティブな受信者は、アドレスの品質を保つためにデータベースから削除します。
  • 大規模な配信を同時にスケジュールしないでください。システム全体に均一に負荷が分散されるまでに 5 ~ 10 分の時間差があります。チームの他のメンバーとの配信のスケジューリングを整合し、最高のパフォーマンスを確保する。マーケティングサーバーが多数の異なるタスクを同時に処理する場合、パフォーマンスが低下することがある。
  • 電子メールのサイズをできるだけ小さくする。電子メールの推奨最大サイズは約 35KB である。電子メール配信のサイズは、送信サーバーに一定のボリュームを生成する。
  • 100 万人以上の受信者の配信など大きな配信は、送信キューにスペースが必要である。これはサーバーの問題ではないが、他の多数の大きな配信と結合して同時に発送されると、送信遅延が発生することがある。
  • 電子メールのパーソナライズによって、各受信者のデータベースからデータが取り出される。多くの個性化要素がある場合は、配信の準備に必要なデータ量を増加する。
  • インデックスアドレス。アプリケーションに使用されている SQL クエリーのパフォーマンスを最適化するために、データスキーマのメインエレメントからインデックスを公表する。

注意:

ISP は、一定期間にわたって非アクティブなアドレスを無効にする場合があります。送信者にはバウンスされたメッセージが送信され、この新しいステータスについて通知されます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー