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