Adobe Experience Manager Assets 実装の環境をサイズ設定する場合は、ディスク、CPU、メモリ、IO、ネットワークスループットなどのリソースに十分な空きがあることを確認することが重要です。 これらのリソースのサイジングには、システムに読み込まれたアセットの数を理解しておく必要があります。わかりやすい指標がない場合は、ライブラリの有効期間から既存のライブラリのサイズを分割し、アセットが作成されたときの割合を見つけることができます。
Assets の実装に必要なディスク領域をサイジングするときによくある間違いは、システムに取り込まれる Raw 画像のサイズに基づいて計算することです。デフォルトでは、 Experience Manager は、元の画像に加えて 3 つのレンディションを作成し、 Experience Manager UI 要素 以前の実装では、これらのレンディションは取り込まれるアセットのサイズの倍と想定されていました。
ほとんどのユーザーは、既製のレンディションに加えてカスタムレンディションを定義します。レンディションに加えて、Assets では、InDesignやIllustratorなどの共通のファイルタイプからサブアセットを抽出できます。
最後に、AEM のバージョン管理機能により、アセットの複製がバージョン履歴に保存されます。パージするバージョンを頻繁に設定できます。 ただし、多くのユーザーはバージョンをシステムに長い間保持するので、ストレージ領域をさらに消費します。
これらの要素を考慮して、ユーザーのアセットを保存するための正確なストレージ領域を計算する手法が必要です。
ステップ 1 から 9 を実行することで、次の数を決定できます。
これらの数を「ネットワークサイジング」スプレッドシートに指定してデータストアに必要な空き容量の合計を決定できます。また、内でアセットのバージョンを管理したりアセットを変更したりした場合の影響を判断するのに便利なツールです。 Experience Manager ディスクの増大時に
ツールに取り込まれているサンプルデータは、前述のステップを実行することの重要性を示しています。データストアのサイズを読み込まれる Raw 画像のみを基準に設定(1 TB)すると、係数が 15 になり、リポジトリサイズが少なく見積もられることがあります。
大規模なデータストアの場合、ネットワークに接続されたドライブ上の共有ファイルデータストアを介して、または S3 データストアを介して、共有データストアを実装できます。 この場合、個々のインスタンスでバイナリのコピーを管理する必要がありません。また、共有データストはバイナリなしのレプリケーションを可能にし、パブリッシュ環境へのアセットのレプリケートやインスタンスのオフロードに使用される帯域幅を減らすのに役立ちます。
データストアはプライマリとスタンバイのオーサーインスタンス間で共有し、プライマリインスタンスで加えられた変更をスタンバイインスタンスで更新するのにかかる時間を最小化できます。ワークフローのオフロードでオーバーヘッドを減らすように、プライマリのオーサーインスタンスとオフロードのオーサーインスタンス間でデータストアを共有することをお勧めします。また、オーサーインスタンスとパブリッシュインスタンス間でデータストアを共有し、レプリケーション中のトラフィックを最小化することもできます。
データストアの共有が常に推奨されるとは限りません。いくつかの落とし穴が存在します。
共有データストアは、インフラストラクチャに単一障害点をもたらすことがあります。次のシナリオを検討してみましょう。システムにオーサーインスタンスが 1 つ、パブリッシュインスタンスが 2 つあり、それぞれ独自のデータストアがあるとします。いずれか 1 つがクラッシュしても、残りの 2 つは引き続き稼動します。ただし、データストアが共有されている場合、1 つのディスクに障害が発生すると、インフラストラクチャ全体がダウンします。このため、データストアを簡単に復元できる場所に共有データストアのバックアップが必要です。
共有データストアには AWS S3 サービスをデプロイすることをお勧めします。これにより、通常のディスクアーキテクチャと比較して、障害が発生する確率を大幅に減らします。
共有データストアは、ガベージコレクションなどの操作を複雑にします。通常、スタンドアロンのデータストアのガベージコレクションは、1 つのクリックで開始できます。しかし、共有データストアの場合は、単一のノードで実際のコレクションを実行することに加えて、そのデータストアを使用する各メンバーでマークスイープ操作が必要になります。
AWS の操作では、EBS ボリュームの RAID アレイを構築するのではなく、(S3 を介して)1 つの中央ロケーションを実装することで、複雑さやシステム上の操作リスクが大幅に軽減されます。
共有データストアでは、すべてのインスタンス間で共有されるネットワークにマウントされたドライブにバイナリを保存する必要があります。これらのバイナリはネットワーク経由でアクセスされるので、システムのパフォーマンスに悪影響が及びます。 ネットワーク接続やディスクアレイを高速化することで、その影響を一部軽減できます。しかし、これにはコストがかかります。AWSを操作する場合、すべてのディスクはリモートで、ネットワーク接続が必要です。 エフェメラルボリュームでは、インスタンスが開始または停止するときにデータが失われます。
S3 の実装では、バックグラウンドの書き込みスレッドにより待ち時間が発生します。バックアップ手順では、この待ち時間やオフロード手順を考慮する必要があります。S3 のアセットは、オフロードジョブが開始するときに S3 に存在していない場合があります。また、バックアップを作成するときに Lucene のインデックスが未完成のままになることがあります。これには、S3 データストアに書き込まれ、別のインスタンスからアクセスされる、時間に左右されるすべてのファイルが該当します。
次の要素によってリソースが消費されるので、ノードストアやドキュメントストアの正確なサイジングを特定するのは困難です。
バイナリはデータストアに保存されるので、各バイナリが空き容量を一部占有します。大部分のリポジトリのサイズは 100 GB を下回ります。ただし、最大で 1 TB のサイズの大きなリポジトリが存在することもあります。また、オフラインコンパクションを実行するには、コンパクション済みのリポジトリをコンパクション前のバージョンの横に書き直すための十分な空き容量がボリュームに必要です。経験則としては、ディスクのサイズをリポジトリの予想サイズの 1.5 倍にすることです。
リポジトリの場合は、IOPS レベルが 3000 を超える SSD またはディスクを使用します。 IOPS がパフォーマンスのボトルネックとなる可能性を排除するために、CPU の入出力待機レベルを監視して問題の兆候を早めに把握するようにしてください。
Assets には、他の多くの プロジェクトよりネットワークのパフォーマンスが重要になる使用例がいくつかあります。Experience Managerお客様は高速なサーバーを使用できますが、システムからアセットをアップロードおよびダウンロードするユーザーの負荷をサポートするのに十分な大きさでないネットワーク接続の場合、処理が遅くなっているように見えます。 ~へのユーザのネットワーク接続のチョークポイントを決定する良い方法がある Experience Manager 時刻 Experience Manager ユーザーエクスペリエンス、インスタンスのサイズ設定、ワークフローの評価およびネットワークトポロジに関するアセットの考慮事項.
次に Experience Manager WebDAV プロトコルの非効率性により、デスクトップアプリケーションを混在させると、ネットワークの問題がより深刻になります。
この非効率性を説明するために、アドビは OS X 上で WebDAV を使用してシステムのパフォーマンスをテストしました。3.5 MB の InDesign ファイルが開かれて編集され、変更が保存されました。以下の観察を行った。
WebDAV を介したファイルの平均保存時間を分析したところ、帯域幅が 5~10 Mbps のレベルにまで上昇するに連れて、パフォーマンスが劇的に上昇することがわかりました。このため、システムに同時にアクセスする各ユーザーのアップロード速度は 10 Mbps 以上、帯域幅は 5~10 Mbps 以上にすることをお勧めします。
詳しくは、 トラブルシューティング Experience Manager デスクトップアプリ.
実装をサイジングするときは、システムの制限事項を頭に入れておくことが重要です。提案された実装がこれらの制限を超える場合は、クリエイティブの戦略(例:アセットを複数の Assets の実装全体で分割する)を採用してください。
メモリ不足(OOM)の問題を起こす要因はファイルのサイズだけではありません。画像のサイズにも依存します。AEM を開始する際にヒープサイズを高く指定することで、OOM の問題を回避できます。
また、 com.day.cq.dam.commons.handler.StandardImageHandler
0 より大きい中間一時ファイルを使用するように Configuration Manager のコンポーネントを使用します。
データストア内のファイル数は、ファイルシステムの制限により 21 億に制限されています。おそらくリポジトリについては、データストアの制限に到達するかなり前に、ノードが多すぎることによる問題に直面します。
レンディションが誤って生成される場合は、Camera Raw ライブラリを使用します。ただしこの場合、画像の長いほうのサイズが 65000 ピクセルを超えてはいけません。また、画像に 512 MP (512 *) を超える値を含めることはできません1024 *1024 ピクセル )'です。 アセットのサイズは取るに足らない.
標準搭載の (OOTB) でサポートされているTIFFファイルのサイズを、 Experience Manager ピクセルサイズなどの追加の要因が処理に影響を与えるためです。 可能性がある Experience Manager では 255 MB OOTB のファイルを処理できますが、18 MB のファイルサイズは処理できません。後者のファイルの構成要素は、前者に比べて異常に多い数のピクセルなのでです。
デフォルトでは、 Experience Manager では、最大 2 GB のファイルサイズのアセットをアップロードできます。 AEMで非常に大きなアセットをアップロードするには、 非常に大きなアセットをアップロードするための設定.