3

いくつかのIIS6/Server2003ボックスで実行されているWebアプリがいくつかあります。彼らはうまく走り、幸せです。これらはすべてasp.netWebアプリであり、.NET3.5を使用します。

WebアプリをIIS7/Server 2008に移行することを検討する正当な理由があるとすれば、それは何でしょうか。

4

3 に答える 3

7

IIS7 は、「プラグイン可能」という概念で一から書き直されています。IIS7 はこれまで以上に拡張性があります。リクエスト パイプライン全体が作り直され、リクエストをより簡単に操作できるようになりました。

パフォーマンスの観点から、これらの変更はすぐに認識できます。IIS6 用に開発されたサイトを、互換性を維持しながら「クラシック」アプリケーション プールで実行できますが、パフォーマンスが大幅に向上します。これまでに行った非科学的評価では、IIS7 テスト マシンでレガシ アプリケーションの読み込み時間が約 20% 短縮されました。

もちろん、「クラシック」モードで実行しなければならない理由は興味深い補足事項です。global.asax 内には、アプリケーションの開始時に HttpContext に触れるプリフェッチがあります。具体的には、IIS7 では許可されていない事前キャッシュが行われます。そのため、「クラシック」モードから切り替える前に、いくつかの変更を行う必要があります。

于 2008-11-29T15:46:31.733 に答える
3
  1. 最終的に、Microsoft は Server 2003 のサポートを終了します。確かに、それは数年先のことではないので、今日のあなたには影響しません。
  2. ASP.NET MVC のサポートが改善されました。これはおそらく私たちのほとんどにとって大きな問題です。ASP.NET MVC を IIS6 で動作させることはできますが、ジャンプするためのいくつかの困難があります。

もっと教えてあげたいのですが、私自身はまだ Server 2008 を使っていません。おそらく、Vista (職場でも自宅でも使用しています) には 2008 と「同じ」IIS7 があり、UI は確かに非常に似ていますが、そこでの私の経験があなたの質問に役立つとは思いません。

于 2008-11-12T19:17:22.473 に答える
2

管理対象言語でパイプライン コンポーネントを作成する能力。以前は、特定の種類の Web 要求を処理する ISAPI フィルターを作成する場合、C++ で作成する必要がありました。これで、古き良き .NET コードを使用できます。これにより、さまざまなタイプのリクエストを処理するための再利用可能なパイプライン コンポーネントを作成できるため、より多くのカスタマイズが可能になります。たとえば、すべての .js ファイル リクエストは ScriptCompressor パイプライン コンポーネントにルーティングされ、多くのキャッシュ可能性が設定された状態で圧縮されて返されます。

MVC の改善されたサポートはこれにリンクされています。II7 を拡張機能なしでリクエストを .NET にルーティングするように設定できるため、http://www.yourwebsite.com/customer/1などの「よりクリーンな」URL を設定せずに使用できます。使用しているサーバー テクノロジの種類を明らかにする拡張子が表示されますが、最近では非常に流行りではありません。

于 2008-11-12T19:25:42.567 に答える