Microsoft のドキュメントのどこかで、ASP.NET のweb.config のコンテンツがキャッシュされていることを読みました。それが本当なら、それはどこにキャッシュされていますか?メモリ内またはディスク上?
フォローアップの質問: web.config に頻繁にアクセスする必要がある場合、パフォーマンスに関する考慮事項はありますか?
Microsoft のドキュメントのどこかで、ASP.NET のweb.config のコンテンツがキャッシュされていることを読みました。それが本当なら、それはどこにキャッシュされていますか?メモリ内またはディスク上?
フォローアップの質問: web.config に頻繁にアクセスする必要がある場合、パフォーマンスに関する考慮事項はありますか?
メモリにキャッシュされ、ディスクにキャッシュしても意味がありません。すでにディスク上にあります。
まず、ASP.NET では、HttpContext オブジェクトのGetSection
メソッド (これは ASP.NET によって管理されるキャッシュされたコピーを使用します) を介して構成セクションに確実にアクセスする必要があります。
構成値へのアクセスのパフォーマンスは、Section オブジェクト (GetSection によって返されるオブジェクト) の内部実装の関数です。ConfigurationSection
は、プロパティに対するすべての要求で読み取ることができる DOM ノードのラッパーとして機能するだけです。OTH 内部で値をキャッシュし、変更を監視することができます。
私のアドバイスは、コードをシンプルに保ち、必要な値にアクセスするだけGetSection
で、他の場所に値のコピーを保持しようとするのではなく、GetSection
複数をフェッチする場合は、リクエストの期間中、返されたオブジェクトへの参照を必ず維持することです。そこからの価値。
web.configはメモリにキャッシュされていると思います(System.Web.Configurationのオブジェクトインスタンス)。これらは、.configファイルが変更されたときにリロードされます(したがって、Webアプリがリロードされます)。
これらのオブジェクトをヒットしても、パフォーマンスのボトルネックになる可能性はほとんどありません。ただし、解析などを行う必要がある場合は、解析されたオブジェクトを保持することをお勧めします。
[追加]私は(少なくとも私が思うに)あなたのappsettingsのためにあなたのglobal.asax.csファイルに静的プロパティを作成することをお勧めします。これらのプロパティはapplication_startメソッドでインスタンス化し、Webアプリ全体で使用できます。これにより、コード全体でハードコードされた文字列(構成キー)を使用できなくなります。
メモリにキャッシュされます。ディスクにキャッシュすることは、頻繁にアクセスされ、簡単に保存できるデータ構造に変換できる形式になっているものにはあまり意味がありません。私のアドバイスは、それを保存するために思いついたスキームと同じくらい速く、おそらくもっと速いので、自由にアクセスすることです。
私のアドバイスは、データがキャッシュされるという単純な理由から、他の変数と同じように使用することです。global.asax で静的変数を作成すると、より多くのコードを書かなければならなくなります。どんなに計画的であっても、開発段階で appconfig に変数を頻繁に追加する可能性は非常に高くなります。
ASP .NET には 2 種類のキャッシュがあります。
アプリケーション キャッシング - メモリ制限、時間制限、およびその他の依存関係に基づく内部オブジェクト キャッシュ
ページ出力キャッシュ - サーバーでレンダリングされたページ キャッシュ。どちらもメモリベースです。ディスクではありません。