問題タブ [esi]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
zend-framework - Varnish/ESI および Zend Framework を使用したキャッシュとページ ビュー
最終的には数か月後に検討する必要があるいくつかのシナリオがあります。それまでの間、議論について熟考できるように、そこに質問を投げかけます。
アプリケーション スタックに Zend Framework を使用しています。サーバーキャッシングにAPCを使用しています(アプリケーションが分散されていても、memcacheが私に利益をもたらすとは思わないため、memcacheではなく)。
私のアプリケーションは JavaScript なしで動作するように構築されており、JavaScript をサポートするために、ページを分割して JavaScript 対応バージョンをレンダリングします。
単純なページを分析すると、おそらくその 80% がコア機能であり、すべてのユーザーに対してキャッシュできます。次に、その 20% がそのユーザー向けにカスタマイズされます。たとえば、表示したい場合があります
- 最近閲覧した 5 件のアイテム
- お気に入りのアイテム
これら 2 つの「ウィジェット」は、各ユーザーに固有のものです。これらのコンポーネントに ESI を使用することを検討していましたが、Zend Framework アプリケーションで最も消費量が多いのはブートストラップとディスパッチ プロセスであることに気付きました。したがって、私のアプリケーションがキャッシュなしで現在 80 ミリ秒かかるとします。相対時間の 90% がブートストラップとプラグイン フックで費やされているように、ESI を使用してこれら 2 つの「ウィジェット」をロードすると、各ページに効果的に負荷がかかることになります。キャッシュされたページごとに別の 80 ミリ秒のリクエストを開始するためです。
その場合、カスタマイズされたウィジェット/スニペットを JavaScript 経由でロードすることをお勧めします。これは、最初のページがロードされた後に取得できます。これの明らかな利点は、キャッシュされるリクエストは常に 1 つだけであり、最初のページ (キャッシュされる) が提供された後、カスタマイズされたものはすべて 1 つのリクエストでプルされることです。
最大のパフォーマンスを探している場合、これはより良い解決策のように思えますか?
zend-framework - Varnish と ESI を使用してページ ビュー カウントを増やす
ドキュメント全体をキャッシュするために Varnish を使用している場合、ページ ビュー カウントもインクリメントするメカニズムを教えてください。
たとえば、eBay などのオークション リストがあり、ページ全体が変更されることはないとわかっているため、ページ全体をキャッシュしたいとします。
このリスティングのページ ビュー数を増やすにはどうすればよいでしょうか。
私のアプリケーションが Zend Framework から実行されているとしましょう。Redis でページ ビュー カウントをインクリメントする node.js サーバーに ESI (Edge Side Include) を作成するのは正しいでしょうか?
100% サポートされ、正確なページ ビュー リクエスト数が得られるものを探しています。(リクエストの重複についても心配していません。アプリケーション ロジックで処理して、1 つの IP がページ ビュー カウントを無効にしないようにします)。
zend-framework - Zend Framework 1.11 プロジェクト内で Varnish を実装する方法
私は Varnish についてあまり知りませんが、私が知る限り、ESI タグをビュー内に含める必要があります。それは正しいですか?
このようなアーキテクチャの実装に関するフィードバックはありますか?
ESI タグを設定するためのビュー ヘルパーをいくつか見つけましたが、それらが本当に効率的かどうかはわかりません。
Varnish を使用してホームページを 10 秒から 30 秒間キャッシュしたいと考えています。
ZFでそれを行うのは簡単ですか?
symfony - Symfony2、Varnish、および ESI が奇妙な動作を引き起こす
私は次の設定を持っています:
(mod_php で Apache を使用した場合と同じ動作) My Varnish config:
で ESI がオンになっていapp/config/config.yml
ます。symfony で次のルートを構成しました。
/esiouter
s-maxage 60 を/esiinner
使用し、esi-include for (「プレーンな」esi-tag または twig-render 関数を使用{'standalone': true}
):<esi:include src="/esiinner" />
/esiinner
s-maxage 10 を使用 (esi-include で取得)
symfonyで AppCache を有効にするとweb/app.php
、ESI タグが評価されるため、ワニスはそれらを取得せず、Content-Length
ヘッダーがあり、コンテンツはチャンクされません。AppCache を無効にすると、ワニスは ESI タグを評価し、コンテンツをチャンクして送信し、Content-Length
ヘッダーはありません。
Varnish がチャンクされた応答を送信し、esi ブロックをバッファリングせず、ページ全体を送信しないのはなぜですか? ESI を使用して Symfony アプリケーションの前で Varnish を使用している場合、Symfony の AppCache を使用する必要がありますか?
validation - Symfony2 ホームページの HTTP キャッシュの検証と独立した ESI
Symfony2 でブログと同じ構造のプロジェクトを設計しています。
私のホームには記事が表示され、ログインへのリンク、またはログインしている場合はアカウントへのリンクがあるサイドバーがあります。
私のサイドバーは ESI です。私の質問: ホームページに検証キャッシュを設定した場合 (前回の記事の更新日によって異なります)、サイドバーはこのキャッシュとは無関係にそのコンテンツを表示しますか? そうでなければ、これを行う別の解決策はありますか? (記事リストをESIとして設定していますが、そのESIは検証キャッシュを持つことができますか?)。
回答ありがとうございます
varnish - html コメントでの ESI ブレークのワニス
私は drupal サイトを運営しており、esi サポートを実装しています。
これまでのところ、次のようなブロックに基本的なesiサポートを実装するとうまくいきました:
タグ内に HTML コメントがない限り、これは非常にうまく機能しました。しかし、esi 内に html コメントがある場合、html コメントの一部のみが削除されます。これにより、次のすべての html がコメント アウトされ、表示されなくなります。
ワニスで処理した後は次のようになります。
html からすべてのコメントを削除することは可能ですが、それは解決策とは思えません。
誰かに同様の問題がありましたか?私はいくつかの助けにとても感謝しています
symfony - Symfony 2 のエッジ サイド インクルードと検証キャッシュ
Symfony 2 の ESI で検証キャッシュを使用することは可能ですか?
HttpFoundation Responseクラスを見ると、 isNotModified がどのように機能するかがわかります。
問題は、ESI $request->headers->get('If-Modified-Since'); です。$request->getEtags() は ESI で何も返さないため、キャッシュは決して新鮮ではありません!
$request の解決策はありますか?
検証 HTTP キャッシュが ESI で機能しない場合、部分をキャッシュする別の方法はありますか?
ありがとうございました !
cdn - トラフィック数の少ない CDN を使用することは現実的ですか?
Web トラフィックが比較的少ないにもかかわらず、エッジ サイド インクルードを使用して CDN でホストしたいアプリケーションがあります。これは、Akamai のような有名な CDN で可能ですか? そして、それはいくらかかりますか?MaxCDN は良い第一歩のように見えますが、エッジ サイド インクルードはできないと思います。
varnish - ESIを処理しないワニスには以下が含まれます
ローカル環境でESIインクルードを処理するようにVarnishをセットアップしようとしています。
仮想マシンでワニスを実行していて、コンテンツはホストマシンで実行されています。
「index.html」と「test.html」の2つのファイルがあります。これらは両方とも、Apacheサーバーのdocrootにある「esi」というフォルダーに保存されます。
index.html
test.html
ワニスはポート8000の仮想マシンで実行されています。したがって、ここからアクセスします:http: //192.168.56.101 :8000/esi/
仮想マシンの/etc/varnish/default.vclで、ファイルの最後に次の構成を追加しました。
すべてのリクエストでESIを処理する必要があるという考えで(これを機能させようとするだけで悪い習慣があったとしても気にしないでください:))
http://192.168.56.101:8000/esi/をロードしたときの結果は次のとおりです。
すなわち。ESIはマークアップに表示され、処理されていません。
ワニスログを確認しましたが、エラーはなく、ESIに関連するものもありません。
誰かが私がここで間違っていることを見ることができますか?さらに情報が必要な場合はお知らせください。ありがとう
caching - ワニスとESI:並行して取得することと可能な回避策
私は、ESIでVarnishを使用して、トラフィックの多いフォーラムのようなWebサイトのページコンテンツをキャッシュすることを調査しています。
コンテキスト:訪問者のみのコンテンツをキャッシュしたい(接続されたユーザーは実際に異なる表示を持ち、絶対に新鮮なコンテンツが必要になります)。それでも、訪問者の場合、ページの一部は動的である必要があります:-たとえば、訪問者に依存するモジュールの場合、cachableではありません(表示されたページのリアルタイム分析が提供される「提案」ウィジェットを考えてみてください。ビーコン)-たとえば、「最新の投稿」ウィジェットや非常に変化する広告キャンペーンの場合、15mnの小さなTTLでキャッシュ可能。
現在、Apache / PHP / symfony / memcacheを使用してページをキャッシュし、社内でESIのようなメカニズムを使用しています。キャッシュからのページが解析され、特定のタグが解釈されます(Webサービスやデータベースへの呼び出しを含む)。サーバー時間は約700ミリ秒であるため、これは十分なパフォーマンスではありません。
このソリューションの代わりに、Varnish+ESIを使用できます。ページに含まれるESIの総数は15に達する可能性があります。フェッチするESIの実際の数はそれより少なくなりますが、ESIのTTLを考えるとそれほど多くはありません。重要な問題は、VarnishがESIを並列ではなく順次フェッチすることであり、これは受け入れられません。この機能は、Varnishのロードマップのどこか遅いところにあります。
それで、
ワニスとESIの使用経験は何ですか?ESIの数、応答時間の増加はありますか?
並列ESIフェッチを使用した回避策またはその他の深刻で構成可能な(VCLが良かった)リバースプロキシを知っていますか?
そうでない場合、同等のユースケースにどのような優れたキャッシュ戦略を使用しますか?
ありがとう、P。