[PaaS のみ]{class="badge informative" title="Adobe Commerce on Cloud プロジェクト（Adobeが管理する PaaS インフラストラクチャ）およびオンプレミスプロジェクトにのみ適用されます。"}

設定のベストプラクティス

Commerceには、応答時間を改善し、スループットを向上させるために使用できる多くの設定やツールが用意されています。

Cron ジョブ

Commerce での非同期操作はすべて、Linux の cron コマンドを使用して実行されます。 正しく設定するには、cron の設定と実行 ​ を参照してください。

インデクサー

インデクサーは、Update on Save モードまたは Update on Schedule モードで実行できます。 Update on Save モードは、カタログまたは他のデータが変更されるたびに、直ちにインデックスを作成します。 このモードでは、ストア内の更新操作とブラウジング操作が低強度であることを前提としています。 これにより、高負荷時に重大な遅延が発生し、データが使用できなくなる可能性があります。 パフォーマンスを上げる目的で スケジュールに従って更新 を使用することをお勧めします。これは、データ更新に関する情報を保存し、特定の Cron ジョブを通じてバックグラウンドで一部でインデックスを実行するからです。 Commerce/System/Tools 設定ページで、各 Index Management インデクサーのモードを個別に変更できます。 Customer Grid インデックスは、常に Update on Save モードに設定する必要があります。

キャッシュ

実稼動環境でストアを起動する場合は、System / Tools / Cache Management ページですべてのキャッシュをアクティベートします。 効率的な実稼働ページキャッシュソリューションなので、Varnish を使用することを強くお勧めします。

非同期メール通知

「非同期メール通知」設定を有効にすると、チェックアウトと注文処理のメール通知を処理するプロセスがバックグラウンドに移動します。 この機能を有効にするには、Stores/Settings/Configuration/Sales/Sales Emails/General Settings/Asynchronous Sending に移動します。 詳しくは、『 ​ 管理者ユーザーガイド ​ の セールスメール を参照してください。

非同期順序データ処理

ストアフロントで集中的な販売が発生すると同時に、Commerce が集中的な注文処理を実行している場合があります。 データベースレベルでこれら 2 つのトラフィックパターンを区別するように Commerce を設定して、対応するテーブルの読み取り操作と書き込み操作の競合を回避できます。 順序データは非同期で保存およびインデックス作成できます。 注文は一時的なストレージに配置され、衝突することなくOrder Management グリッドに一括で移動されます。 このオプションは、Stores/Settings/Configuration/Advanced/Developer/Grid Settings/Asynchronous indexing から有効にできます。 詳しくは、『 ​ 管理者ユーザーガイド ​ の スケジュールされたグリッドの更新 を参照してください。

非同期設定の保存

多数のストアレベル設定を含むプロジェクトの場合、ストア設定の保存に法外な時間がかかったり、タイムアウトが発生したりする可能性があります。 Async Config モジュールは、コンシューマーを使用してメッセージキュー内の保存を処理する cron ジョブを実行することで、非同期設定の保存を有効にします。 AsyncConfig は、デフォルトでは 無効 になっています。

コマンドラインインターフェイスを使用して AsyncConfig を有効にできます。

bin/magento setup:config:set --config-async 1

set コマンドは、app/etc/env.php ファイルに次の内容を書き込みます。

...
   'config' => [
       'async' => 1
   ]

次のコンシューマーを開始して、キュー内のメッセージの処理を先入れ先出し方式で開始します。

bin/magento queue:consumers:start saveConfigProcessor --max-messages=1

延期された在庫更新

大量の売上高が発生する場 Commerce、注文に関連する在庫の更新を延期できます。 これにより、操作の数が最小限に抑えられ、注文配置プロセスが高速化されます。 ただし、このオプションはリスクが高く、店舗でバックオーダーが有効になっている場合にのみ使用できます。これは、このオプションによって在庫数がマイナスになる可能性があるためです。 このオプションにより、店舗のチェックアウトフローのパフォーマンスが大幅に向上し、必要に応じて簡単に在庫を補充できます。 サイトで延期された在庫更新を有効化するには、Stores/Settings/Configuration/Catalog/Inventory/Product Stock Options/Use Deferred Stock Update に移動します。 詳しくは、{2Adobe Commerce ユーザーガイド ​ インベントリの管理 を参照してください。

クライアントサイドの最適化設定

Commerce インスタンスのストアフロントの応答性を改善するには、デフォルトまたは開発者モードで管理者に移動して、次の設定を変更します。

Stores-> Configuration -> Advanced -> Developer:

「Enable JavaScript Bundling」オプションを有効にすると、Commerceで、すべての JS リソースを、ストアフロントページに読み込まれる 1 つまたは一連のバンドルに結合できます。 JS をバンドルすると、サーバーへのリクエストが少なくなり、ページのパフォーマンスが向上します。 また、ブラウザーが最初の呼び出し時に JS リソースをキャッシュし、それ以降のすべてのブラウジングで再利用するのに役立ちます。 このオプションでも、すべての JS がテキストとして読み込まれるので、遅延評価が行われます。 ページで特定のアクションがトリガーされた後にのみ、コードの分析と評価が開始されます。 ただし、すべての JS コンテンツが最初の呼び出しで読み込まれるので、最初のページの読み込み時間が非常に重要なストアには、この設定はお勧めしません。

バンドルのヒント

顧客セグメントの検証

多数の ​ 顧客セグメント ​ を持つマーチャントの場合、顧客ログインや買い物かごへの製品の追加など、顧客のアクションによってパフォーマンスが大幅に低下する可能性があります。

顧客処理トリガー顧客セグメントの検証プロセス。これにより、パフォーマンスが低下する可能性があります。 デフォルトでは、Adobe Commerceは各セグメントをリアルタイムで検証し、一致する顧客セグメントと一致しない顧客セグメントを定義します。

パフォーマンスの低下を避けるために、Real-time Check if Customer is Matched by Segment システム設定オプションを いいえ に設定して、単一の組み合わせ条件 SQL クエリで顧客セグメントを検証できます。

この最適化を有効にするには、Stores/Settings/Configuration/Customers/Customer Configuration/Customer Segments/Real-time Check if Customer is Matched by Segment に移動します。

この設定により、システム内に多数の顧客セグメントがある場合の顧客セグメント検証のパフォーマンスが向上します。 ただし、​ 分割データベース ​ 実装では動作しません。また、登録済みの顧客がない場合でも動作しません。

データベースのメンテナンススケジュール database

ステージングインスタンスと実稼動インスタンスには、定期的なデータベースバックアップを実行することをお勧めします。 バックアップ操作の I/O 集約性により、バックアップの遅延や潜在的な問題が発生する場合があります。 複数の環境に対してデータベースプロセスを同時に実行すると、使用可能なリソースの競合が原因で、実行速度が低下する可能性があります。

パフォーマンスを向上させるには、バックアップを一度に 1 つずつ、ピーク以外の時間に連続して実行するようにスケジュールします。 この方法では、I/O 競合が回避され、特に小規模なインスタンスや大規模なデータベースの場合に完了までの時間が短縮されます。

例えば、ストアへの訪問回数が少ない場合は、実稼動データベースのバックアップをスケジュールし、その後にステージングデータベースをバックアップすることをお勧めします。

グリッド内の製品数を制限

大規模なカタログの製品グリッドのパフォーマンスを向上させるには、Stores/Settings/Configuration/Advanced/Admin/Admin Grids/Limit Number of Products in Grid システム設定設定を使用して、グリッド内の製品数を制限することをお勧めします。

このシステム設定は、デフォルトでは無効になっています。 有効にすると、グリッド内の製品数を特定の値に制限できます。 Records Limit は、カスタマイズ可能な設定で、デフォルトの最小値は 20000 です。
Limit Number of Products in Grid 設定が有効で、グリッド内の製品数がレコード制限を超えている場合、限られたレコードのコレクションが返されます。 制限に達すると、検出された合計レコード数、選択したレコード数、ページネーション要素がグリッドヘッダーに表示されなくなります。

グリッド内の製品の総数が制限されている場合、製品グリッドのマスアクションには影響しません。 製品グリッドのプレゼンテーションレイヤーにのみ影響します。 例えば、グリッド内の 20000 製品の数が制限されている場合、ユーザーが Select All をクリックし、Update attributes の一括アクションを選択して、一部の属性を更新します。 その結果、20000 しいレコードの限られたコレクションではなく、すべての製品が更新されます。

製品グリッドの制限は、UI コンポーネントで使用される製品コレクションにのみ影響します。 その結果、すべての商品グリッドがこの制限の影響を受けるわけではありません。 Magento\Catalog\Ui\DataProvider\Product\ProductCollection を使用している場合のみ。
製品グリッドのコレクションは、次のページでのみ制限できます。

製品グリッドを制限しない場合は、結果コレクションの項目を Records Limit よりも少なくするために、より正確にフィルターを使用することをお勧めします。