0

私は Varnish に非常に慣れていませんが、ドキュメントを読んだ後、ESI 機能により memcached サーバーの必要性がほとんど取り除かれているように思えます。Web ページは複数の ESI インクルードから動的に構築でき、それぞれがキャッシュされます。 Varnish によって適切に (たとえば、ホームページは、長期間キャッシュされるかなり静的なレイアウトと、数時間だけキャッシュされる今日のニュースを含むより動的な部分から構築される場合があります)。

まだテストしていませんが、App サーバーではなく Varnish でいくつかの部分から Web ページを構築すること (memcached を使用) のパフォーマンス上の利点はおそらく大きいと思います。

何か不足していますか？Web ページの生成に引き続き memcached を使用することをお勧めするのはどのような場合ですか? 複数の Web ページが同じ大量のデータベース要求を使用しているが、結果が同じ方法でレンダリングされない場合、おそらくデータベース キャッシュとして? 他のアイデアはありますか？

あなたの洞察に感謝します。

4

1 に答える 1

2

通常、ページで最も重いのは、ページの動的な部分、つまり ESI リクエストを通じてロードする部分です。そのため、ページの動的部分もアプリ サーバーにキャッシュする必要がある可能性が高くなります。アプリの静的部分は、Varnish が前になくても、おそらくすぐに読み込まれます。

memcached を使用するか、他の種類のキャッシュ (ファイル キャッシュなど) を使用するかは、好みの問題です。いつものように、コンテンツのキャッシュを開始する前に、クエリをプロファイリングして最適化し、インデックスが適切に機能していることを確認する必要があります。一部のクエリがまだ重すぎて、最初のページの読み込みに大幅な遅延が発生する場合は、それらをスケジュールされたタスクに移動して結果をサマリー テーブルに保存し、そこからコンテンツをアプリに提供することをお勧めします。

いずれにせよ、Varnish wikiで示されているように、Varnish を使用して ESI インクルードをキャッシュすることもできます (キャッシュする必要があります) 。

sub vcl_fetch {
    if (req.url == "/test.html") {
        esi;  /* Do ESI processing */
        set obj.ttl = 24 h;
    } elseif (req.url == "/cgi-bin/date.cgi") {
        set obj.ttl = 1m;
    }
}
于 2013-03-17T09:54:45.180 に答える