0

現在、さまざまなgetパラメーターに基づいてXMLページを作成するサービスがあります。パラメータの数が増え、さまざまな組み合わせの数も増えているため、ニスキャッシュのヒット率が低下しています。TTLを増やしたため、ヒット率は上がりましたが、私は次のことを考えています。

Edge Side Includesに出くわし、考えています。毎回50個の要素を含むXMLのページを作成する場合、ニスが1つのドキュメントに結合される50個のESIを含むページを生成できますか？

なぜあなたが尋ねる50のESI要素？各XML要素自体は1つのURLによって非常に簡単にキャッシュされますが、フィルターの組み合わせにより、多数の異なる完全なXMLドキュメントが生成されるためです。

したがって、1つのリクエストが最初の10個のXML要素を除外したとしても（get paramsを確認しないため）、ESIが使用されるため、各要素はキャッシュからフェッチされます。

これはサーバー上でどのくらい重いでしょうか？これを行うのは理にかなっていますか？ESIは非常に高価であり、その場合は意味がありません。

アップデート

まず、メモリが不足することはなく、Nukeはゼロです。現在、ヒット/ミスの比率は0,4で、ttlは4時間です。これは、私の意見ではひどいものです...これらすべての組み合わせ（国、ロケールなど）が原因です。さらに悪いことに、Tomcatは100％の使用率になり、ワニスが1〜3％の調査に留まっている間にハングしました。私の直感では、ESIにニスを塗ると、サブドキュメントによってTomcatがさらに保護され、容量が増えることを覚えておいてください。アイテムを奇妙にNukeする必要はありませんでした。つまり、最大1GBのキャッシュでは、キャッシュエントリの有効期限が切れる前にアイテムがいっぱいになることはありません。各サブドキュメントをキャッシュすると、メモリ制限に達してアイテムの削除を開始する可能性があると確信しています...しかし、ニスは、最近使用されていないアルゴリズムを使用していませんか？

4

1 に答える 1

1

クエリのさまざまな組み合わせがたくさんあるキャッシュコレクションを包括することは、一般的に最善の決定ではありません。特定のクエリの組み合わせは、他の組み合わせよりもはるかに頻繁にアクセスされる可能性があります（たとえば、SEOジュースがたくさんある組み合わせ、サイト上でリンクを配布/共有/リンクしている組み合わせ、またはユーザーとの関連性が高い組み合わせなど） ）、したがって、それらは選択的にキャッシュする必要があります。長いttlですべてをキャッシュするだけの問題は、URLスペースが大きい場合、頻繁にアクセスされるメモリとnukeリソースが不足し、アクセス頻度の低いものをキャッシュすることになります。

ページごとに含まれるESIの制限はありません。説明するアプローチは、xmlサブドキュメントのヒット率が非常に高いと想定した場合の優れた戦略です。ワニスのキャッシュヒットは非常に軽量であるため、ページが50のキャッシュヒットの複合である場合でも、キャッシュがない場合と比較して非常に優れたパフォーマンスを発揮すると思います。esiに含まれるサブドキュメントのヒット率が低く、各ページに大量のサブドキュメントがある場合、バックエンドで毎回サブドキュメントをレンダリングするよりもパフォーマンスが低下します。知識に基づいた決定を下せるように、次のシナリオで負荷テストを行うことを強くお勧めします。

  1. キャッシュなし、バックエンドは毎回サブドキュメントをレンダリングします。
  2. サブドキュメントをフラグメントとしてレンダリングするESI、0％のキャッシュヒット。
  3. サブドキュメントをフラグメントとしてレンダリングするESI、50％のキャッシュヒット。
  4. サブドキュメントをフラグメントとしてレンダリングするESI、100％キャッシュヒット。

これにより、ヒット率が低下するにつれてパフォーマンスがどのように低下​​するかがわかりやすくなり（線形ではない可能性があるため、0％、50％、100％を実行します）、理論上、どの程度のキャッシュによってパフォーマンスが向上するかがわかります。私にとって最良の解決策は、esi：定期的にアクセスされるサブドキュメントの「ワーキングセット」にフラグメントを含め、サブドキュメントがワーキングセットにない場合はバックエンドに直接レンダリングすることの組み合わせであると思われます。

于 2013-07-17T18:04:28.473 に答える