設定のベストプラクティス
Commerceには、ページの応答時間を向上させるだけでなく、スループットを向上させるために使用できる多くの設定とツールが用意されています。
Cron Jobs
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を使用することを強くお勧めします。
非同期メール通知
Asynchronous email notifications設定を有効にすると、チェックアウトと注文処理のメール通知を処理するプロセスがバックグラウンドに移動します。 この機能を有効にするには、Stores> Settings > Configuration > Sales > Sales Emails > General Settings >Asynchronous Sendingに移動します。 詳しくは、管理者ユーザーガイド の セールスメール を参照してください。
非同期注文データ処理
Commerceでの集中的な注文処理と同時に、ストアフロントでの集中的な販売が発生することもあります。 対応するテーブルで読み取り操作と書き込み操作の競合を避けるために、Commerceを構成して、データベースレベルでこれらの2つのトラフィックパターンを区別できます。 注文データを非同期で保存し、インデックスを作成できます。 注文は一時的な保管として保管され、衝突することなくOrder Managementのグリッドに一括で移動されます。 このオプションは、Stores> Settings > Configuration > Advanced > Developer > Grid Settings >Asynchronous indexingから有効にできます。 詳しくは、管理者ユーザーガイドの「 スケジュールされたグリッドの更新」を参照してください。
非同期設定の保存
多数のストアレベル設定を持つプロジェクトの場合、ストア設定の保存には膨大な時間がかかったり、タイムアウトが発生したりする可能性があります。 非同期設定 モジュールは、消費者を使用してメッセージキュー内の保存を処理する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に移動します。 詳しくは、Adobe Commerce ユーザーガイド の 在庫管理 を参照してください。
クライアントサイド最適化設定
Commerce インスタンスのストアフロントの応答性を向上させるには、デフォルトモードまたは開発者モードで管理者に移動し、次の設定を変更します。
Stores-> Configuration -> Advanced -> Developer:
Enable JavaScript Bundling オプションを有効にすると、CommerceがすべてのJS リソースを1つまたはストアフロントページに読み込まれる一連のバンドルに統合できるようになります。 JSをバンドルすると、サーバーへのリクエストが少なくなり、ページのパフォーマンスが向上します。 また、ブラウザが最初の呼び出しでJS リソースをキャッシュし、それ以降のすべてのブラウジングに再利用するのに役立ちます。 このオプションでは、すべてのJSがテキストとして読み込まれるため、遅延評価も行われます。 特定のアクションがページ上でトリガーされた後にのみ、コードの分析と評価が開始されます。 ただし、すべてのJS コンテンツが最初の呼び出しに読み込まれるため、最初のページ読み込み時間が非常に重要なストアでは、この設定はお勧めしません。
バンドルのヒント bundling-tips
- 縮小とバンドルには、サードパーティ製ツール（r.jsなど）を使用することをお勧めします。 Commerceの組み込みメカニズムは最適ではなく、代替として提供されます。
- HTTP/2 プロトコルをアクティブ化することは、JS バンドルを使用する代わりに良い方法です。 プロトコルは、同じ利点の多くを提供します。 クラウドインフラストラクチャプロジェクトのAdobe Commerceでは、デフォルトで有効になっています。
- JSやCSS ファイルの結合など、非推奨の設定を使用することはお勧めしません。これらの設定は、ページのHEAD セクションで同期ロードされたJSにのみ設計されています。 この手法を使用すると、バンドルが発生し、JS ロジックが正しく動作しない可能性があります。
顧客セグメントの検証
多数の顧客セグメント を持つマーチャントは、顧客ログインや製品のカートへの追加など、顧客の行動に伴ってパフォーマンスが大幅に低下する可能性があります。
顧客の行動は、顧客セグメントの検証プロセスをトリガー化します。これにより、パフォーマンスが低下する可能性があります。 デフォルトでは、Adobe Commerceは各セグメントをリアルタイムで検証し、一致する顧客セグメントとそうでない顧客セグメントを定義します。
パフォーマンスの低下を回避するには、Real-time Check if Customer is Matched by Segment システム構成オプションを No に設定して、単一の複合条件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を使用しているユーザーのみ。
商品グリッドコレクションは、次のページでのみ制限できます。
- カタログ商品グリッド
- 関連/アップセル/クロスセル商品の追加グリッド
- 製品をバンドル製品に追加
- 製品をグループ製品に追加
- Admin Create Order Page
製品グリッドを制限しない場合は、結果コレクションに Records Limit より少ない項目を含めるように、フィルターをより正確に使用することをお勧めします。