VarnishがMagentoサイトをキャッシュできるようにするには、どのような修正が必要であるかの良い実例を見つけるのに苦労しています。

理想的には、無効/有効にするものやそれらを探す場所などのタスクのリストが欲しいです。また、これらの変更が機能するように設計されたVarnish構成を用意しておくとよいでしょう。

Magentoのパフォーマンスガイドはワニスについて多くのことを話しているので、以前に行われたことは知っていますが、実際に機能させる方法については説明していません。

ここに公式モジュールがあります。必要なものがすべて含まれています（ワニスの構成、モジュール、...）

ワニスはあなたに合っていますか？

ワニスは、Magentoのパフォーマンスのすべてではありません。ボットやウィンドウショッパーからの負荷を相殺するのは素晴らしいことですが、実際に店舗を高速化するための最初の呼びかけではありません。

実際、ワニスの実装は最後でなければなりません、ストアのパフォーマンス変更であるます。ページの読み込み時間を確認してからドロップするだけです。Magentoはそれなしで配信できます（たとえば、ページの読み込み時間は600ミリ秒未満）。

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

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

a） TTLが非常に高いため、4日前からの検索クエリは今日でも有効です
。b）サイトの足跡が非常に大きいため、URLが非常に短時間で入力されます。

また、すべての店舗がワニスに適しているわけではないことも考慮する必要がありますます。ユーザーがカスタマージャーニーの早い段階でパーソナルセッション（ログイン、カートへの追加など）を作成することを奨励するサイトは、Varnishが最終的に冗長になることを意味します。

たとえば、プライベートショッピングサイトでは、ユーザーのログインを最初から推奨していますが、これを行う場合、Varnishがキャッシュ可能な一意でないコンテンツを実際に持つことはありません。したがって、ヒット率は大幅に低くなり、ワニスを使用してもまったくメリットはありません。

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

^{magestack.comの好意による画像}

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

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

トラフィックの少ないサイトがある場合は、妥協する必要があります。TTLを増やしてヒット率を高めるか、最新のコンテンツを使用してください。あなたは両方を持つことはできません。はい、クロール/スパイダーツールを継続的に実行できますが、これが消費するリソース、およびクロール可能な膨大なボリュームまたはURL（通常、小規模ストアの場合は数万個）は、単に効果がないことを意味します。そのため、通常、小規模なストアは、適切な FPC拡張機能と高度に最適化されたサーバー構成の恩恵を受けます。

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

ESI

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

Magentoブートストラップがロードされるたびに、パフォーマンスのペナルティが約200ミリ秒になります。コレクションをロードしたり、ブロックなどをレンダリングしたりする前です。 Varnishをバイパスして、Magento自体に直接リクエストを渡すよりも、動的コンテンツにVarnish + ESIを使用すると、ページの読み込み時間が遅くなります。

したがって、ESIを実際に効果的に使用するには、複数の要求を1つの要求に結合できる必要があります。

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

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

ユーザーごとのキャッシュ

次に、ユーザー固有のキャッシュを使用する代替方法があります。非常にトラフィックの少ないサイトがない限り、これは悪い考えです。あなたのヒット率は恐ろしく低いでしょう-訪問者が既に行ったのと同じページを訪れる確率は非常に低いからです。また、顧客ごとに、その6KbページがVarnishのストレージビンでますます多くのスペースを占有します。

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

まあ、私は気にしない、私はただワニスが欲しい

さて、あなたは次のことをする必要があります：

1. ワニスの前に座るようにSSLターミネーターをインストールします（例：stud / pound / nginx）
2. サーバーにニスをインストールする
3. X-Forwarded-For正しく構成されていることを確認してください
4. ストアにニスモジュールをインストールする
5. Varnish VCLをセットアップして、サードパーティの拡張機能を除外します

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

Varnishの実装で最も重要なことは、キャッシュすべきでないコンテンツをキャッシュしないようにすることです。

例えば。

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

等

コアMagento URLについては、ワニスでエスケープできるURIのかなり標準的なリストがあります。

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

ただし、カスタムルート、ルーター、および名前空間を持つ、実行中のカスタム/ 3rdパーティ拡張機能も考慮する必要があります。残念ながら、これらの拡張機能からのURLがキャッシュできるものとできないものを知る簡単な方法はありません。そのため、それぞれをケースバイケースで評価する必要があります。

原則として、Varnishを構成するときはいつでも、それぞれのルート、ルーター、および名前空間を特定し、そこからそこに移動することから始めます。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サーバーのパフォーマンス最適化と同様に、正しく実装および調整を行うと、実際にメリットが得られます。ただし、適切に構成せずにソフトウェアをドロップするだけでは、ストアの速度が低下するだけでなく、遅くなり、安全性が低下し、信頼性が低下します。