ハードウェアの推奨事項
CPU
Web ノード Commerce、キャッシュされていないすべてのリクエストを処理するか、アプリケーションを介してキャッシュできないすべてのリクエストを処理します。 1 つの CPU コアは、2 つ（場合によっては最大 4 つ）の Commerce リクエストを効果的に処理できます。 次の式を使用して、すべての受信リクエストをキューに入れずに処理する必要がある web ノード/コアの数を決定します。
N[Cores] = (N[Expected Requests] / 2) + N [Expected Cron Processes]
ストアの負荷が変化すると予想される場合は、アクティブな販売期間の web ノード/コアの数を手動で増やすことができます。 または、自動スケーリングモデルを使用して web 層を自動的に拡張することもできます。
メモリ
PHP
Magentoの PHP のメモリ要件は、システムのデプロイ方法によって異なります。 一般的に、単一のサーバストアを設定する場合は、PHP メモリを 2G 用に設定することをお勧めします。 パイプラインのデプロイメントを使用してサイトを設定する場合は、ビルドサーバーに 2 GB および web ノードに 1 GB をお勧めします。
シナリオと予想される PHP メモリ要件：
- ストアフロントページのみを提供する Web ノード：256 MB
- 大きなカタログを持つ管理ページを提供する Web ノード：1 GB
- 大きなカタログを持つサイトのインデックスを Commerce cron で作成：256 MB 超（最適なパフォーマンスになるように調整するには advanced-setup を参照）。
- 静的アセッ Commerce のコンパイルおよびデプロイの場合：756 MB
- Commerce Performance Toolkit のプロファイル生成：>1 GB PHP RAM, >16 MB MySQL TMP_TABLE_SIZE およびMAX_HEAP_TABLE_SIZE 設定
MySQL
Commerce データベース（およびその他のデータベース）は、データとインデックスの保存に使用できるメモリ容量の影響を受けます。 データ MySQL インデックス化を効果的に活用するには、使用可能なメモリ量を、少なくともデータベースに保存されるデータのサイズの半分近くに設定する必要があります。
キャッシュ
複数の Commerce をデプロイし、キャッシュに Redis または Varnish を使用する場合は、次の原則に注意してください。
- フルページキャッシュメモリの無効化が有効な Varnish 合は、最も人気の高いページをメモリに保持するために、Varnish に割り当てられる十分なメモリを推奨します
- セッションキャッシュは、Redis の別のインスタンス用に設定するのに適した候補です。 このキャッシュタイプのメモリ設定では、サイトの買い物かごの放棄の戦略と、セッションがキャッシュに残ると予想される期間を考慮する必要があります
- Redis には、最適なパフォーマンスを得るために、他のすべてのキャッシュをメモリに保持するのに十分なメモリが割り当てられている必要があります。 ブロックキャッシュは、設定するメモリ量を決定する際の重要な要素となります。 ブロックキャッシュが、サイト上のページ数（SKU 数×ストアビュー数）に応じて増える
ネットワーク帯域幅
十分なネットワーク帯域幅は、Web ノード、データベース、キャッシュ/セッション・サーバ、その他のサービス間のデータ交換に関する重要な要件の 1 つです。 Commerce はキャッシュを効果的に活用して高パフォーマンスを実現するため、システムは Redis のようなキャッシュサーバーと積極的にデータを交換できます。 Redis がリモートサーバー上にある場合は、読み取り/書き込み操作のボトルネックを防ぐために、Web ノードとキャッシュサーバーの間に十分なネットワークチャネルを提供する必要があります。