カタログ画像のサイズ変更のベストプラクティス
すべてのカタログ画像は、ストアが実稼動環境に移行する前にサイズ変更する必要があります。 実稼動環境で事前に画像のサイズを変更しないと、ページの読み込み中に画像のサイズが強制的に変更されます。これにより、サイトの速度が大幅に低下し、起動後最初の数日から数週間でサーバーの読み込みが増加します。
ゆっくりした道
デフォルトの CLI コマンドを使用して、すべてのイメージのサイズを変更します。
bin/magento catalog:images:resize
このアプローチの欠点は次のとおりです。
- プロセスはシングルスレッドです
- 既にサイズ変更された画像のサイズが変更されます
- プロセスを中断することはできません。これには数日かかる場合があります
速い方法
Adobe Commerce 2.4 では、非同期の画像サイズ変更が導入され、画像のサイズ変更が高速になりました。
-
すべての Web サーバーで、一時的に追加のキューハンドラーを起動します(サーバーあたりの物理プロセッサー数の 2 倍)。
code language-bsh for i in {1.."$((2 * `nproc --all`))"};do bin/magento queue:consumers:start media.storage.catalog.image.resize &;done;
-
キューハンドラーが実行中であることを確認します。
code language-bash pgrep -fl media.storage.catalog.image.resize
-
すべての画像サイズ変更リクエストでキューを埋めます。
code language-bash bin/magento catalog:images:resize --async
-
すべての画像のサイズが変更されたら、プロセスを終了します。
code language-bash pkill -f media.storage.catalog.image.resize
速い道
フロントエンドを使用して画像のサイズを変更する別の方法があります。
このアプローチの利点は次のとおりです。
- プロセスはマルチスレッドです
- プロセスはマルチサーバーです(複数の web ノード、ロードバランサー、
media/
ディレクトリの共有ディスク領域がある場合) - 既にサイズ変更された画像はスキップされます
このアプローチでは 100,000 個の画像のサイズが 8 時間以内に変更されますが、CLI コマンドでは完了するまで 6 日かかります。
- サーバーにログインします。
pub/media/catalog/product
に移動して、ハッシュの 1 つ(例:0047d83143a5a3a4683afdf1116df680)をメモします。- 次の例では、
www.example.com
をストアのドメインに置き換え、ハッシュをメモに記載したドメインに置き換えます。
code language-bash |
---|
|
siege
の欠点は、同時実行性が 10 に設定されている場合、すべての URL を 10 回訪問することです。
code language-bash |
---|
|
code language-bash |
---|
|
-P
引数は、スレッドの数を決定します。
find/curl
の例では、画像が置かれている同じマシンから curl
を実行できる場合の 1 つのライナーです。
code language-bash |
---|
|
先ほどと同様に、www.example.com
を web サイトのドメインに置き換え、-P
を、サーバーがクラッシュすることなく処理できるスレッドの数に設定します。
出力では、ストア内のすべての製品画像のリストが返されます。 使用可能なすべてのサーバーとプロセッサーコアを使用して(siege
またはその他のクローラを使用して)画像をクロールし、他の方法よりも大幅に高速にサイズ変更キャッシュを生成できます。
1 つの画像キャッシュ URL にアクセスすると、画像がまだ存在しない場合は、バックグラウンドですべての画像サイズが生成されます。 また、既にサイズ変更されたファイルはスキップされます。