問題タブ [http-caching]

環境: IIS6 で実行されている ASP.Net 2.0 のサイトで作業しています。VS2005 と VB を使用して、IIS 5.1 を実行する WinXP でローカルに開発しています。

問題: System.web.caching.cache を使用して、いくつかのビジネス レイヤー オブジェクトのキャッシュを作成しようとしています (実際にはキャッシュ レイヤーを作成しています)。これは System.Web 名前空間で利用できるはずですが、アクセスできるのは AspNetHostingPermission、AspNetHostingPermissionAttribute、および AspNetHostingPermissionLevel (プロジェクトで System.Web への参照があり、クラスでインポートされている) だけです。表示されない他のクラス (HTTPRuntime など) もかなりあります (これは、「SQL キャッシュ依存関係の使用」チュートリアルhttp://www.asp.net/web-forms/tutorials/data-access/cachingによるものです)。 -data/using-sql-cache-dependencies-vb )。

私はロープの終わりにいて、これを説明するものをそこに見つけることができないようです. 誰かがこの状況にあり、これを以前に見たことがありますか? これを解決するための助けは大歓迎です!

WCFに実装されたHTTPRESTサービスに取り組んでいます。操作用のHTTPキャッシュ制御ヘッダーを適切に設定したいと思います。

WebOperationContext.Current.OutgoingResponse各メソッドのヘッダーを変更するためにを使用することを含むいくつかの例を見てきました。しかし、正直に言うと、これはお尻の痛みです。特に、ほとんどすべての操作で同じキャッシュ制御ポリシー（キャッシュなし）が使用されるためです。

これを設定するためのエレガントな方法があるに違いないと思います。おそらく、サービスレベルのデフォルトを設定するServiceBehaviorと、特定の操作に対してそれをオーバーライドするOperationBehaviorsの組み合わせですか？それとも、これを行うためのより良い方法がありますか？

私は、ソフトウェアの問題を解決するためにハードウェアを投入することは最善の策ではないと確信しています。そのため、サーバーの1つ（現在2ギガで実行されている）でいくつかのメモリの問題に気付いたとき、System.Web.HttpRuntime.Cacheの使用まで追跡しました。いくつかのサイトでは、これは理にかなっていますが、System.Web.HttpRuntime.Cacheを使用する50のサイトをスローすると、壁が崩れ始めました。

外部キャッシングサーバーのオプションがない場合、グローバルデータ保持に静的クラスまたはシングルトンのいずれかを使用するようにコードを変更することを検討しています（他のオプションは追加のdbリクエストを作成することです）。

データはまだ「メモリ内」にあり、サーバーにより多くのメモリを投入する必要があるかもしれないので、これに変更があるかどうかは完全にはわかりません。

シングルトンクラスまたは静的クラスでSystem.Web.HttpRuntime.Cacheを使用すると、オーバーヘッドが大幅に増加しますか？この問題を解決するために推奨されるアプローチは何ですか？

- アップデート -

現在のファイルキャッシュのメモリ使用量を監視しているときに、同じアプリケーションプール上のいくつかのサイトにアクセスしたときに、この数が急増していることに気付きました。この数はわずか1,000,000（私が想定しているバイト）に跳ね上がりました。アクティブなフラッシュエントリの数が増加してから減少するにつれて、この数は最終的に減少し始めることに気付きました 。

複数のアプリプールでこの数が多いと問題が発生するように見えるので、どうすればこれをすばやくフラッシュできますか？

キャッシュをリッピングするだけでなく（提案されているように、おそらく最善のアイデアではありません）、キャッシュされたオブジェクトの有効期限を短く設定するだけで、より良い結果が得られる可能性がありますか？

実際に XML フィードを使用したいのですが、パフォーマンスの問題がいくつかあります。XML フィードは基本的に、XML を返すパラメータを持つ URL です。

で URL を開き、urllib.urlopen(URL)で応答を解析しxml.dom.minidom.parseます。関連するパーツを取得するよりも、DOM オブジェクトを取得します。

問題は、同じ URL への接続を何度も開かなければならず、まったく同じ XML が返されることです。新しい接続を開く前よりも、結果の XML をキャッシュしたいのですが、既にメモリ内にあるかどうかを確認したいと思います。もちろん、毎時間または他のアルゴリズムでキャッシュをフラッシュする必要があります。

ただし、Djangoでどのように実装できるか少し混乱していますか? または、他のキャッシングの提案はありますか?

ありがとう

ASP.NET ページから SWF ファイルを参照するときは、バージョン番号を SWF URL に追加しますApp.swf?1.1.0.0。最近の更新で、Firefox はバージョン番号が変更された場合でも、キャッシュされた swf を使用し続けましたApp.swf?1.2.0.0。他のブラウザでは、この動作は確認されていません。

他の誰かがこの動作を見たことがありますか? キャッシュを完全に無効にしたくはありません。この時点で、バージョンごとに swf の名前を変更する予定ですApp.1.2.0.0.swf。

ありがとう、

最近、Varnish という http Web アクセラレータに出会いました。私が読んだことによると、Varnish は、リバース プロキシ構成を使用して HTTP サーバーとの HTTP 通信のすべてのプロセスを最適化することにより、Web サイトの配信を高速化します。

私の質問は、キャッシュ メカニズムが静的な html ファイルに至るまで構成されている Web サイトがある場合、Varnish はこれにどの程度の影響を与えるでしょうか? リバース プロキシは、HTTP サーバーが要求を処理するために実行する作業を削減しますか? サーバー側にすべてが広範囲にキャッシュされている場合 (HTTP ヘッダー、Etags、Expires ヘッダー、データベース キャッシング、フラグメント、およびページ キャッシング)、HTTP アクセラレータはこれを改善するためにさらに何をしますか?

Rails で静的アセットを提供しています。それらのほとんどは名前にハッシュが含まれており、遠い将来の有効期限が設定されています。しかし、1 つのファイルについては、名前にハッシュを付けて提供することはできないため、有効期限を制御する必要があります。

すべての静的アセットに適用される application.rb にこれがあります。

1 つのファイルだけに別の max-age を設定する方法はありますか? ActionDispatch::Static特定のファイルの値を後で変更する新しいミドルウェアを作成できることはわかっています (この記事を参照)...しかし、これは、静的アセットではないものであっても、すべての単一の要求に対して実行されます。よりエレガントなソリューションはありますか？

While studying the caching strategies adopted by various search engine websites and Stackoverflow itself, I can't help but notice the subtle differences in the response headers:

Google Search

Yahoo Search

Stackoverflow Search

There must be some logical explanation behind the settings adopted. Can someone care to explain the differences so that everyone of us can learn and benefit?

たとえば、私の Web アプリケーションは、ヘッダーに「キャッシュ制御」が含まれていない応答で http 要求に応答します。クライアント側が比較的短い時間内に同じリクエストを送信した場合、どうなるでしょうか? 応答のキャッシュされたコピーが使用されるため、要求がサーバーに到達する必要はありませんか? それとも、最初と同じようにリクエストがサーバーに送信されますか?

答えが「依存する」である場合、依存関係が何であるかを示してください。ありがとう。

私の質問は、djangoドキュメントのこのセクションを参照しています。

そこには、次のような段落があります。

キャッシングミドルウェアは、キャッシュヘッダーのmax-ageをCACHE_MIDDLEWARE_SECONDS設定の値ですでに設定していることに注意してください。cache_controlデコレータでカスタムmax_ageを使用する場合、デコレータが優先され、ヘッダー値が正しくマージされます。

私の解釈では、デフォルトでは、http-cache関連のデコレータを使用して「Cache-Control」を変更しない限り、djangoサーバーエンドからの応答のhttpヘッダーセクションに「Cache-Control：max-age=600」が含まれます。 "ヘッダー。

上記の解釈を検証するために、簡単な実験を行いました。驚いたことに、ビューでhttp-cache-relatedが使用されていない場合、生成された応答には「Cache-Control」ヘッダーがまったくありません。

公式ドキュメントで説明されているものとは異なる結果が表示されるのはなぜですか？概説された段落を誤解しましたか？

また、応答に「Cache-Control」ヘッダーがない場合、httpキャッシングが含まれていない（つまり、キャッシュされた応答は使用されない）と安全に想定できますか？