Web.configプロダクション環境のパフォーマンス - ベストプラクティス

Question

Visual Studioでは、開発時にweb.configファイルが変更されることがよくありますが、修正される内容はわかりません。また、パフォーマンスの生産環境にどのような影響がありますか構成セクションは重要です。例えば

：

<compilation> 
<compilers> 
<runtime> 
... 

私は必需品ではないと考えてセクションの多くは、それなしで、または別の構成であり、本番環境でのパフォーマンスを向上させることができます。

だから私の質問は：あなたは、パフォーマンスを低下させ、光の設定ファイルを持っていないために、本番環境でのweb.configファイルには何を探している

？

のベストプラクティスは何ですか？

ありがとうございました！

Answer 1

web.configファイルのセクション数は、パフォーマンスとは関係ありません。

一部のマシンは、同じアプリケーションを実行するために、他のものより構成された多くのもの（したがって、サイズの差）が必要になります。

Hasanが指摘したように、web.configはマシンの設定ファイルとマージされています。プロダクション設定で定義されていないmachine.config内のものを定義する1台のマシン（テストと呼ばれます）があります。テストのために、生産に必要な特定のセクションは必要ないかもしれません。

また、特定の項目のマシン設定は異なる場合があります。 Webファームのシナリオでは、マシンの設定ファイルを共通のマシンキーで上書きするのが一般的です。これはパフォーマンスに影響はありませんが、サイトのロードバランシングに成功するかどうかには影響します。

セクションの番号は、パフォーマンスにとって重要ではありません。一方、定義されたセクションの内容は、です。

---

ここでは、パフォーマンスを向上させる方法を示します。これはアプリケーションごとに適用されます。本番環境では、デバッグを無効にし、静的コンテンツのURL圧縮などを有効にします。

ダイナミックコンテンツの圧縮を有効にしたり、特定のディレクトリを設定してコンテンツがキャッシュ可能（/ images、/ css、javascriptなど）していることをブラウザに知らせることもできます。ちなみに、これらは一般的にプロダクション設定ファイルのサイズを大きくし、特定の結果（CSSファイルを変更したいときなど）を持ちますが、一般的にクライアントのパフォーマンスが向上します。

その他の項目については、ロギングをオフにするか、全く異なるロギングストレージプロバイダを使用することがあります。私たちはelmahを使い、私たちのdevボックスはメモリストレージ用に設定されていますが、プロダクションはデータベースサーバを使うように設定されています。パフォーマンス上の問題ではありませんが、確かに懸念事項の1つです。

ここで重要な点は、アプリケーションが特定のプラットフォーム/マシン上で実行できることを確認するために設定ファイルを使用することです。

Answer 2

Web.Configでは、デバッグアセンブリを作成するか、アセンブリをリリースするかを構成できます。 WCF、スレッドプールのパフォーマンスをチューニングすることができます。ログなどを設定できます。

Visual Studioでは、重要な設定は自動的に変更されません。ただし、アプリケーションをデバッグしようとしているときにデバッグアセンブリを有効にするだけです。その場合は確認を求められます。プロダクションでは、デバッグアセンブリを無効にすることができます。

diffmergeツールを使用して、最後のコミット以降に追加されたセクションを確認することをお勧めします。ただし、設定を短くしても必ずしもパフォーマンスが向上するとは限りません。

web.configは、セクションが多いmachine.configとマージされています。だから、セクションを置くことは、通常、あなたがmachine.configのデフォルトを変更していないことを意味します。セクションを追加しても、新しいものを追加しているわけではありません。これは、それ以外の場合にはデフォルト設定を持つようなものを設定していることを意味します。

ベストプラクティスに関する限り、よりメンテナンス可能な短い設定ファイルを用意することをお勧めします。デフォルトで暗黙的に設定されている場合や、それ以外の場合はmachine.configに設定されている場合は、configのデフォルトを再度指定する必要はありません。 VS2010はすでに不要なセクションを避けています。