Magento CEでワニスを使用するために必要な変更が必要です

Question

私は、ワニスがマゼントサイトをキャッシュできるようにするために必要な修正が必要なものの良い実用的な例を見つけるのに苦労しています。

理想的には、無効化/有効化するものやそれらを探す場所など、タスクのリストが必要です。また、これらの変更が機能するように設計されているワニス構成を持つことも良いでしょう。

Magento Performance Guideはワニスについて多くのことを話しているので、以前に行われたことは知っていますが、実際にそれを機能させる方法を説明していません。

Answer 1

彼らは公式モジュールを正しく持っています ここ. 。必要なものがすべて含まれています（ワニス構成、モジュールなど...）

Answer 2

ワニスはあなたにぴったりですか？

Varnishは、Magentoのパフォーマンスのすべてであり、すべてではありません。ボットとウィンドウショッパーからの負荷を相殺するのは素晴らしいことですが、実際にあなたの店をより速くするための最初の呼び出しポートであってはなりません。

実際、ワニスを実装する必要があります 過去 ストアへのパフォーマンスの変更。ページの読み込み時間が表示されたら、Magentoがそれなしで配信できます（例：600msページの読み込み時間など）。

あなたの店はまだ速くする必要があります

ワニスはまだキャッシュをプライミングするために少なくとも1ページのロードを必要とするため、キャッシュされていないパフォーマンスは非常に良いものである必要があることを意味します。一意のURLの大部分（レイヤードナビゲーションヒット、検索クエリなど）は、次のいずれかでない限り、実際にはワニスから提供されることはありません。

a） あなたのTTLは非常に高いので、4日前の検索クエリは今日でも有効です
b） サイトの足音は非常に広大であるため、URLは非常に短い時間で入力されています

また、それを考慮する必要があります すべての店がワニスに役立つわけではありません. 。カスタマージャーニーの早い段階で、ユーザーが個人セッション（ログイン、カートへの追加など）を作成することを奨励するサイトは、ワニスが最終的に冗長になることを意味します。

たとえば、プライベートショッピングサイトでは、オンセットからのユーザーのログインを奨励していますが、これを行うと、ワニスが実際にはキャッシュ可能な非ユニークコンテンツを持っていないことを意味します。したがって、ヒット率は大幅に低くなり、ワニスを使用することで利益はまったくありません。

新鮮なコンテンツまたはより高いヒット率

^{画像提供 Magestack.com}

ワニスを効果的に使用することは、古いコンテンツとサイト上の訪問者の量とのバランスをとることです。

忙しいサイトがある場合 - オッズは、より低いTTLで逃げることができ、それでも高いニスのヒット率を持っています - また、低いTTLを持ち続けます - したがって、新鮮なコンテンツ。そのため、在庫/価格の変更は迅速に反映され、キャッシュは足場の量から継続的に準備されています。

トラフィックの低いサイトがある場合 - その後、妥協する必要があります。 TTLを増やして、より高いヒット率を確保するか、最新のコンテンツを確保します。両方を持っていることはできません。はい、クロール/スパイダーツールを継続的に実行できますが、これが消費するリソースと、rawい（通常は数万人のために」膨大なボリュームまたはURLが 小さい ストア）は、それが単に効果的ではないことを意味します。したがって、通常、小さな店はより多くの利益を得るでしょう 良い FPC拡張機能と高度に最適化されたサーバー構成があります。

しかし、もちろん、ユーザーがログインしている場合でもワニスを使用できますが、ユーザーごとのキャッシュやESIはどうですか？

ESIS

ESIは、キャッシュにコンテンツを保持できるようにするための優れたユーティリティであり、ページにダイナミックブロックを持つことができます。ただし、効果的に使用するには、最小限のコールバックの量を最小限に抑える必要があります。少しヘッドスタートがあります モジュール このプロセスの基礎として使用できます - その中のセキュリティホールを締めてください。デフォルトでは非常に安全ではありません - ロードできないレイアウトハンドルに制限はありません

Magento Bootstrapがロードされるたびに、それは約200msのパフォーマンスペナルティになります - コレクションをロードする/ブロックをレンダリングする前に、3倍以上のESIを持っている場合、あなたが終わった可能性がありますページの読み込み時間は、ワニスを使用してワニス+ESIを使用して、ワニスをバイパスしてマゼント自体に直接リクエストを渡すよりも、時間の負荷時間です。

したがって、ESIを実際に効果的に使用するには、単一のリクエストで複数のリクエストを組み合わせることができなければなりません。

たとえば、20の製品をリストするカテゴリビューページには、正確な在庫レベルを表示する必要があります。したがって、ページ上の各ブロックにESIを使用します。それは20倍のESI株式リクエストです。在庫リクエストは非常に軽量ですが、それらの20倍を同時に実行するとパフォーマンスが粉砕されます。代わりに、20個の製品のブロック/コレクション全体を提供し、その1倍のリクエストを取得することができます。しかし、コレクションをロードしてレンダリングすることは、おそらくページ上で最も遅い要素です。したがって、あなたはあまり得られませんでした。

ESIを使用すると、適切な計画と実行が効果的に必要です。または、ワニスを使用しないよりも遅いサイトがあります。

ユーザーあたりのキャッシュ

次に、ユーザー固有のキャッシュを使用する代替手段があります。あなたが非常に低トラフィックサイトを持っていない限り、これは悪い考えです。ヒット率は恐ろしく低くなります - 訪問者がすでに行ったのと同じページをヒットしたオッズは非常に低いためです。また、各顧客について、その6KBページは、ワニスストレージビンのスペースをますます占有しています。

たとえば、1GBをワニスに割り当てた場合。ユーザーが訪問ごとに8ページを表示する典型的なサイトでは、それらのページの平均6つが一意になります。そのため、1MBのストレージあたり28人の訪問者です。次に、画像を因数分解します。CSSとJS -これらは（ありがたいことに）一般的ですが、おそらく利用可能なストレージの7〜800MBを占めるでしょう。これにより、200MBのストレージが残り、5,600人のユニーク訪問者に十分なキャッシュが残ります。

まあ、私は気にしません、私は単にワニスが欲しい

さて、次のことをする必要があります。

1. ワニスの前に座るためにSSLターミネーターを取り付けます（例：スタッド/ポンド/nginx）
2. サーバーにワニスをインストールします
3. 設定してください X-Forwarded-For 正しく
4. インストールa ワニスモジュール あなたの店で
5. ワニスVCLSをセットアップして、サードパーティの拡張機能を除外します

最初の3つのポイントはこの答えの範囲を超えているので、私はそれを自分に任せて処理します。ポイント4は子供の遊びであり、ポイント5で - 読み続けてください。

ワニスの実装で最も重要なことは、あなたが確実にすることです 一度もない キャッシュされるべきではないキャッシュコンテンツ。

例えば。

• 支払いゲートウェイコールバック
• カートの概要
• お客様のアカウントの概要
• チェックアウト（およびそれぞれのAJAXコール）

等

コアMagento URLには、ワニスで逃げることができるURIのかなり標準的なリストがあります。

admin|checkout|customer|catalog/product_compare|wishlist|paypal

ただし、カスタムルート、ルーター、名前空間を備えたカスタム/サードパーティの拡張機能も検討する必要があります。残念ながら、これらのエクステンションからのURLがキャッシュされることができるものとできないことを知る簡単な方法はありません。そのため、ケースバイケースでそれぞれ評価する必要があります。

原則として、ワニスを構成するときはいつでも、それぞれのルート、ルーター、名前空間を識別し、そこから占有して行くことから始めます。私たちはSSHを介してこれを行います：

grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community 
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local 

これにより、URLの決定的なリストが得られませんが、ほぼ確実にスターターを提供します。

キャッシュされることになっていないコンテンツを決してキャッシュしないことがどれほど重要かを強調することはできません。 結果は壊滅的なものになる可能性があります。

要約すれば

他のMagentoサーバーのパフォーマンスの最適化と同様に、正しく実装および調整された場合、実際に利益をもたらす可能性があります。しかし、それを適切に構成せずにソフトウェアを落とすだけで、ストアをより速くすることができないだけでなく、潜在的に遅くなり、より不安定で、信頼性が低くなります。