Magento Enterpriseフルページキャッシュの事前準備

Magento Enterpriseのフルページキャッシュのパフォーマンス上の利点は、かなりよく知られています。あまり知られていないかもしれないことは、これの完全な利益を実現するために、特に数ページしかなく、したがってオーガニックなトラフィックを利用している大規模な製品セットで、完全に実装され、ホットでなければならないことです十分な速さでプライムします。

Magentoには、サイトをクロールし、早朝にFPCを暖めるための組み込みのcronジョブが含まれています。

早朝のジョブの実行に時間がかかりすぎて、他のジョブの実行をブロックすることによって引き起こされる問題を見て、聞いたことがあります。私が持っているいくつかのアイデアは次のとおりです。

• 生成されたサイトマップファイルのすべてのページをクロールするシェルスクリプトを作成します。
• 別個のcrontabエントリと短いPHPスクリプトを使用して、Magentoをブートストラップし、クローラープロセスを直接実行します。

これについての考えや経験は大歓迎です！

MageSpeedTestのように、ファイルと組み合わせて包囲を使用できます。sitemap.xml

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

次に実行する

siege -i -c 1 -t 7200s -f urls.txt

^{ここからソースされたコンテンツ。}

まったくしません-まったく。今まで。これを何度も繰り返しますが、

キャッシング！=パフォーマンス

あなたのサイトは、FPC（またはそのためのニス）を追加せずに高速である必要があります。コンテンツが準備されていないときが常にあります（上記のシナリオ）。

ロードされていないストアでは、FPCを使用したページのロード時間は、FPC以外の場合よりもそれほど印象的ではありません。Magentoは< 400ms、標準のキャッシュ（カテゴリ/製品/検索ページ）でのページの読み込み時間を非常に快適に処理できます。FPCはそれを実現し< 80msますが、注意点があります。

1. 在庫/価格情報は、無効化またはTTL有効期限まで期限切れです

2. 新しいアイテム/より関連性の高い検索は、無効化またはTTL有効期限まで期限切れです

   等

FPC（またはニス）への依存が悪い考えである理由

キャッシュが手動でプライミングされるようにしたい場合、いくつかの理由が考えられます

1. キャッシュの準備を整えるのに十分な自然の足がありません（「FPCが役立つ場所」を参照）
2. あなたのサイトはそれらなしでは遅すぎます

すべてをキャッシュすることはできません

ネストされた2レベルの深さ、5つのフィルター可能な属性、それぞれ5つの属性オプション、および1000の製品だけで5つのカテゴリーを持つストアを利用する場合。それは多くの可能な組み合わせです。

25のオプションから選択し、1つを最大5回連続で選択します- 私は統計学者ではありませんが、それは知っています...（属性オプションの数が完全に減少しないと仮定して）

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

私が想像するように、3回のクリックで上記のシナリオは起こりそうにありません。利用可能な製品の数は、顧客が製品を見つけるのに十分なほど減少したでしょう。だからそれが...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations 

次に、5つのカテゴリ、つまり625のURLを掛けます。この段階では、小さなカタログについて話しており、すべての製品URLを完全に無視しています。

また、is_anchoron を使用してネストされたカテゴリがある場合、指数関数的に増加することも考慮していません。

そのため、ページのそのボリュームをクロールするには-ページの読み込み時間が最初から良いと低いことを期待する必要があります。それにより、迅速な軽量プロセス（クロールの目的に反する）になります-またはTTLが期限切れになる前に完了するのに十分な時間。

ページのページ読み込み時間が0.4秒で、8コアのCPUがあった場合-...

625 * 0.4 = 250 / 8 = 31 seconds

0.5分、悪くない-しかし、2秒のページ読み込み時間があったと想像してください

625 * 2 = 1250 / 8 = 156 seconds

しかし、可能な限り最大のシナリオをとった場合

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

これが実稼働サーバーで、15分間100％のCPU負荷がかかります。希望するTTLに比例してクロール速度を低下させます。

したがって、コンテンツのTTLを3600秒にしたい場合、クロールは4倍遅くなる可能性があります。クロール専用のCPUは25％のみです。カテゴリコンテンツの準備を整えるためだけのリソースです。この段階では、製品、検索語、追加のストアビューも考慮していません。

実際、catalog_url_rewritesテーブル内の組み合わせの大きさを見れば（階層化されたナビゲーションのパラメーターも考慮されていないため）、クロールする必要のあるURLの数がわかります。

すべての店舗は確かに異なりますが、私が家に帰ろうとしているのは、サイトをクロールしてFPCをプライムすることは実用的ではないということです。開始するのが速いことを確認してください。

FPCが役立つ場所

FPCのメリットが発揮されるのは、非常に負荷の高い店舗です-本当に高いレベルのトラフィックがあり、キャッシュは自然に継続的に素足でのみプライミングされます。

FPCは、一般的に要求されるコンテンツのインフラストラクチャオーバーヘッドを削減することで機能します。Magentoバックエンドへの繰り返しの呼び出しを削減します。

そのため、FPCは、ページの読み込み時間を短縮するのではなく、リソースの使用量を削減するために、トラフィックレベルが非常に高い場合に展開するのに最適であることがわかりました。

誰が気に、私はまだクロールしたいです

さて、あなたは2つのオプションを持っています

1. テンプレートからのクロール（例：サイトマップ）
2. ページごとにリンクを抽出し、それぞれをクロールする

そして、これらの両方を行う多くのユーティリティがあります、これらは私が知っているものです

1. mage-perftest
2. HTTrack
3. ヌッチ
4. スフィダー
5. Crawler4j

Mage-Perftestを使用する

Mage-Perftestを使用してストアを非常に簡単にクロールできます。最初にダウンロードしてください

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

次に、Magentoサイトマップを使用してクロールプロセスを定義します（URLが<loc></loc>タグでラップされている場合は、任意のURLのサイトマップを作成してカスタマイズできます）。次のコマンドは、サイトマップファイルからすべてのURLを読み取り、1440分（1日）にわたってURLをクロールします（PHPのみ）。サーバーが20％CPUまたは平均負荷2を超えると、クロールは一時的に停止します。

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2  

1日にクロールされたURLが1000個ある場合、それは約10です。86秒ごとに1リクエスト〜0.011 RPSの目標

私は最近ブログの投稿のために私の完全な暴言を保存しますが、その間に私の小さなキャッシュウォーマーでピークを迎えwfpcます。

パフォーマンスのテスト

Magentoサイトのパフォーマンスをテストできます

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC温暖化

また、FPCを暖めると、sitemap.xmlのすべてのURLにヒットします。

./wfpc -w http://mymagentosite.com/sitemap.xml

必要に応じてリクエスト間に遅延を入れることもできます。リクエスト間の遅延は1秒です。

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

テストモードはランダムに10個のURLにヒットするだけなので、FPCを暖めると、テストモードを実行してFPCがどの程度の違いをもたらすかを調べることができます。

考え

個人的には、ウォーマーは理にかなっていると思います...約40ページの小さなサイトでは、ダウンロード時間はFPCによってほぼ半分に短縮されます。APCuをバックエンドとしてLesti_FPCを使用している40,000近くの製品がある大規模なサイトでは、キャッシュに200MBを少し使用していますが、これは率直に言って8GB運用サーバーにはありません。