1


0

私はゆっくりと進化している動的WebサイトをJ2EEから提供しています。 サーバーの応答時間と負荷容量は、クライアントのニーズには不十分です。 さらに、その場限りの要求は、同じアプリケーションサーバー/データベース上で実行されている他のサービスに予期せぬ影響を与える可能性があります。 私はその理由を知っていて、短期間でそれらに対処することはできません。 私はHTTPキャッシュのヒント(有効期限、etagsなど)を理解しています。この質問の目的のために、私は負荷を減らす機会を最大化したと仮定してください。

システム内のすべてのURLをブルートフォースでトラバースしてキャッシュを準備してから、そのキャッシュの内容をクライアントの近くにある地理的に分散したキャッシュサーバーにコピーすることを考えています。 私はSquidかApache HTTPD mod_disk_cacheを考えています。 私は1つのコピーをプライミングして(手動で)キャッシュの内容を複製したいです。 私は奴隷の間に連合や知性を必要としません。 データが変更されてキャッシュが無効になったら、おそらく1泊に1回、マスターキャッシュを更新してスレーブバージョンを更新します。

誰もがこれをやったことがありますか? それは良い考えですか? 私が調査すべき他の技術はありますか? 私はこれをプログラムすることができますが、私はオープンソース技術ソリューションの構成を好むでしょう

ありがとう

3 回答


0


動的に作成されたRSSフィードの負荷を減らすために、以前は Squidを使用しましたが、非常にうまく機能しました。 それはちょうどそれがあなたが望むように動くようにするためにいくらかの慎重な設定と調整を必要とします。


0


プライムされたキャッシュサーバを使うことは素晴らしいアイディアです(私はwgetとSquidを使って同じことをしました)。 ただし、このシナリオではおそらく不要です。

あなたのデータはかなり静的なもので、問題はサーバーの負荷であり、ネットワークの帯域幅ではないようです。 一般に、問題は2つの領域のうちの1つに存在します。

  1. データベースクエリがDBサーバーにロードされます。

  2. Web /アプリケーションサーバーにビジネスロジックがロードされます。

これはhttp://www.onjava.com/pub/a/onjava/2005/01/05 / jspcache.html [キャッシュオプションのJSP固有の概要]です。

クエリ結果をキャッシュするだけでパフォーマンスが大幅に向上しました。 60秒の期間でキャッシュを追加しても、データベースサーバーの負荷を劇的に減らすことができます。 JSPには、インメモリキャッシュのためのいくつかのオプションがあります。

あなたが利用できるもう一つの分野は出力キャッシュです。 つまり、ページのコンテンツは1回作成されますが、出力は複数回使用されます。 これにより、WebサーバーのCPU負荷が劇的に軽減されます。

私の経験はASPですが、JSPページでもまったく同じメカニズムが利用できます。 私の経験では、ほんの少しのキャッシュでも、1秒あたりの最大リクエスト数が5〜10倍増加すると予想できます。


0


ここでは階層型キャッシングを使用します。ご想像のとおり、Squidをリバースプロキシサーバとしてアプリケーションサーバの前に配置します。その後、オリジンキャッシュを指すSquidを各クライアントサイトに配置します。

地理的な待ち時間がそれほど重要でない場合は、おそらく、予定していたようにオリジンキャッシュをプライミングしてから、クライアントの要求に基づいてリモートキャッシュをプライミングするだけで済みます。 言い換えれば、クライアントでキャッシュを展開するだけで、オリジンキャッシュを準備する以外に必要なことがすべてあるかもしれません。