パフォーマンスの最適化の確認

パフォーマンスの最適化は多くの側面から発生する可能性がありますが、ほとんどのシナリオで考慮すべき一般的な推奨事項がいくつかあります。 一般的な推奨事項には、インフラストラクチャ要素の設定の最適化、Adobe Commerceのバックエンド設定、アーキテクチャの拡張性計画などがあります。

インフラストラクチャ

次のセクションでは、インフラストラクチャの最適化に関する推奨事項について説明します。

DNS ルックアップ

DNS ルックアップは、ドメイン名が属する IP アドレスを見つけるプロセスです。 ブラウザーは、DNS 検索が完了するまで待ってから、各リクエストに対して何かをダウンロードできるようにする必要があります。 ページ全体の読み込み時間を改善するには、DNS 参照の削減が重要です。

コンテンツ配信ネットワーク（CDN）

CDN を使用すると、アセットのダウンロードパフォーマンスを最適化できます。 Adobe Commerceは Fastly を使用します。 Adobe Commerceのオンプレミス実装がある場合は、CDN レイヤーの追加も検討する必要があります。

Web 待ち時間

データセンターの場所は、フロントエンドユーザーの web 待ち時間に影響を与えます。

ネットワーク帯域幅

十分なネットワーク帯域幅は、Web ノード、データベース、キャッシュ/セッション・サーバ、その他のサービス間のデータ交換に関する重要な要件の 1 つです。

Adobe Commerceは高パフォーマンスを実現するためにキャッシングを効果的に使用するため、システムは Redis のようなキャッシングサーバーと積極的にデータを交換できます。 Redis をリモートサーバーにインストールする場合は、読み取り/書き込み操作のボトルネックを防ぐために、web ノードとキャッシュサーバーの間に十分なネットワークチャネルを提供する必要があります。

オペレーティングシステム（OS）

オペレーティングシステムの設定と最適化は、他の高負荷 web アプリケーションと比較した場合、Adobe Commerceで同様です。 サーバーが処理する同時接続の数が増えると、使用可能なソケットの数が完全に割り当てられることがあります。

Web ノードの CPU

1 つの CPU コアで、約 2～4 個のAdobe Commerce リクエストをキャッシュなしで効率的に処理できます。 すべての受信リクエストをキューに入れずに処理するために必要な web ノード/コアの数を判断するには、次の式を使用します。

N[Cores] = (N [Expected Requests] / 2) + N [Expected Cron Processes])

PHP-FPM 設定

これらの設定を最適化するかどうかは、様々なプロジェクトのパフォーマンステストの結果によって異なります。

Web サーバー

nginx を web サーバとして使用するために必要な再設定は少しだけです。 nginx web サーバのパフォーマンスが向上し、Adobe Commerce（nginx.conf.sample）のサンプル設定ファイルを使用して簡単に設定できます。

データベース

この文書では、各ストアとAdobeが異なるため、MySQL の詳細なチューニング手順は提供されませんが、一般的な推奨事項を提示することができます。

Adobe Commerce データベース（およびその他のデータベース）は、データとインデックスの保存に使用できるメモリ容量の影響を受けます。 MySQL のデータインデックス化を効果的に使用するには、使用可能なメモリ量を、少なくともデータベースに保存されるデータのサイズの半分に近づける必要があります。

innodb_buffer_pool_instances 設定を最適化して、同じインスタンスにアクセスしようとする複数のスレッドの問題を回避します。 max_connections パラメーターの値は、アプリケーションサーバーで設定された PHP スレッドの合計数に関連付ける必要があります。 次の式を使用して、innodb-thread-concurrency の最適な値を計算します。

innodb-thread-concurrency = 2 * (NumCPUs+NumDisks)

セッションキャッシュ

セッションキャッシュは、Redis の別のインスタンス用に設定するのに適した候補です。 このキャッシュタイプのメモリ設定では、サイトの買い物かごの放棄の戦略と、セッションがキャッシュに残ると予想される期間を考慮する必要があります。

Redis には、最適なパフォーマンスを得るために、他のすべてのキャッシュをメモリに保持するのに十分なメモリが割り当てられている必要があります。 ブロックキャッシュは、設定するメモリ量を決定する際の重要な要素です。 ブロックキャッシュは、サイト上のページ数（SKU 数×ストア表示数）に応じて増えます。

ページキャッシュ

Adobeでは、Adobe Commerce ストアのフルページキャッシュに Varnish を使用することを強くお勧めします。 PageCache モジュールはコードベースにまだ存在しますが、開発目的でのみ使用する必要があります。

Web 層の前の別のサーバーにワニスをインストールしてください。 すべての受信リクエストを受け入れ、キャッシュされたページコピーを提供する必要があります。 保護されたページでワニスが効果的に機能するように、ワニスの前に SSL ターミネーションプロキシを配置できます。 Nginx はこの目的に使用できます。

Varnish のフルページキャッシュメモリの無効化は効果的ですが、Adobeでは、最も人気のあるページをメモリに保持するために、十分なメモリを Varnish に割り当てることをお勧めします。

メッセージキュー

メッセージキューフレームワーク（MQF）は、モジュールがキューにメッセージを公開できるようにするシステムです。 また、メッセージを非同期で受信するコンシューマーも定義します。 Adobe Commerceは、メッセージを送受信するためのスケーラブルなプラットフォームを提供するメッセージングブローカーとして RabbitMQ をサポートします。

パフォーマンステストと監視

e コマースプラットフォームの機能を概算するには、各実稼動リリース前のパフォーマンステストを常にお勧めします。 立ち上げ後も監視を継続し、ピーク時の処理に備えた拡張性とバックアップ計画を立てます。

検索 search-heading

Elasticsearch（OpenSearch）はAdobe Commerce バージョン 2.4 以降で必要ですが、2.4 より前のバージョンでは有効にすることもベストプラクティスです。

運用モデル

前述の一般的なインフラストラクチャ最適化の推奨事項に加えて、特定のビジネスモードと規模のパフォーマンスを向上させるアプローチもあります。 このドキュメントでは、シナリオごとに異なるので、それらすべてに関する詳細なチューニング手順については説明しませんが、Adobeの参考までに、いくつかの大まかなオプションを提供している場合があります。

ヘッドレスアーキテクチャ

ヘッドレス専用の別のセクションがあります。 要約すると、ストアフロントのレイヤーがプラットフォーム自体から分離されています。 それはまだ同じバックエンドですが、Adobe Commerceではリクエストを直接処理しなくなり、代わりにGraphQL API を介したカスタムストアフロントのみをサポートするようになりました。

Adobe Commerceを最新の状態に維持

Adobe Commerceの最新バージョンを実行すると、常にパフォーマンスが向上します。 新しいバージョンがリリースされるたびにAdobe Commerceを最新の状態に保つことができない場合でも、Adobe Commerceでパフォーマンスを大幅に最適化するときは、引き続き アップグレードすることをお勧めします。

例えば、2020 年、Adobeは Redis レイヤーの最適化をリリースし、多くの非効率性、接続の問題、Redis とAdobe Commerce間の不要なデータ転送を修正しました。 2.3 から 2.4 の全体的なパフォーマンスは昼と夜で、Redis の最適化のおかげで、買い物かごと、チェックアウト、同時ユーザーが大幅に向上しました。

データモデルの最適化

多くの問題は、不正なデータモデル、適切に構造化されていないデータ、インデックスがないデータなど、データに起因します。

接続をいくつかテストしている場合は問題ありませんが、実稼動環境にデプロイすると、パフォーマンスが大幅に低下する場合があります。 システムインテグレーターは、データモデル（特に製品属性）を設計する方法、不要な属性を追加しない方法、ビジネスロジックに影響する必須の属性（価格、在庫の可用性、検索など）を保持する方法を理解していることが重要です。

ビジネスロジックに影響を与えないが、ストアフロントに存在する必要がある属性については、それらを複数の属性（JSON 形式など）に結合します。

プラットフォームのパフォーマンスを最適化するために、PIM や ERP から取得したデータや属性からストアフロントにビジネスロジックが不要な場合は、その属性をAdobe Commerceに追加する必要はありません。

スケーラビリティを考慮した設計

スケーラビリティは、キャンペーンを実施し、トラフィックのピーク時間に頻繁に直面する企業にとって重要です。 スケーラブルなアーキテクチャとアプリケーション設計により、ピーク時にリソースを増やし、ピーク後にリソースを削減できます。