ASP.Net Webサイトの読み込みが遅いのはなぜですか？[閉まっている]

事例として、各ページの読み込みにかなりの時間がかかる多くの.aspx Webサイトにアクセスしました。

私の経験はユニークですか？

そうでない場合、なぜASP.Net Webサイトの読み込みが遅くなるのですか？

編集：約7年後（2017年12月29日）になりました。良いニュースは、おそらくこの問題はあまり見られないことです。おそらく、Googleが読み込みが遅いサイトにペナルティを課し始めたためでしょう。現在、Vultrプライベート仮想サーバーで実行されているASP.NET MVCを使用して良好な結果を得ています（Azureを試したところ、Azureの速度が遅すぎました）。サイトが取得するトラフィック量に対して遅すぎるか、仕様が不十分なハードウェア。-HK1

私が考えることができる5つの可能性（いくつかの高度なキャッシングテクニックなどは別として）：

• ASP.NETのWebサーバーの不適切なサイズ設定（つまり、クラシックASP向けのサイズのサーバーで問題ないと考えた）

• <compilation debug="true"/>web.config から削除するのを忘れて、最適ではないコードを取得する。

• 初めてのJIT

• JITの前およびJITに加えてコンパイルが必要な、ページに埋め込まれたコード（コンパイルされた分離コードとは対照的）。

• ViewState（ASP.NET WebFormsの場合）が大きくなりすぎます。

どうやらこれは答えに値するかもしれません。

多くの要因が影響する可能性があります。この瞬間を使用しているサイトは.NET上に構築されており、通常は非常に高速です（ダウンタイム/メンテナンス期間を除く）。

あなたが行くそれらのサイトの開発者はあなたにたくさんのデータを押したり、遅い接続、または過負荷のサーバーなどを使っているかもしれません。また、多分プレイ中に非常識なJavaScriptを使用していて、IEを実行していますか？それともフラッシュ？

何をしているのか本当にわからない場合は、ASP.NET WebFormsを使用すると、フォームのコントロールをドロップすることで、httpのステートレスな性質を隠すことさえでき、Webアプリケーションを作成できます。それは機能しますが、特にデータアクセスレイヤーに、インデックスのないSQL Expressデータベースからすべてを選択する生成されたクエリが含まれる場合、そのような開発では効率的なコードは生成されません。

Webアプリケーションが実際にどのように機能するかを理解している人々によって開発された、高速のasp.net Webサイトはたくさんあります。これにはこのサイトが含まれます-個々の要求の処理をより詳細に制御し、.aspx拡張子を表示しないASP.NET MVCを使用します。

私が同じことに気づいたので、ここでただの推測です。.aspサイトは、データセンターでホストされるのではなく、企業のサーバーでセルフホストされる傾向がある（傾向は傾向に注意）と思われます。そのため、それらはハードウェア上で実行されることが多く、実際には高速Webトラフィック用に設計された接続ではありません。私は常温核融合のサイトもこれに苦しんでいるのではないかと思う。

Webサイトが読み込まれると（application.startイベント）、すべてをメモリに読み込むのに時間がかかります。IISの設定に応じて、非アクティブ状態が約20〜30分続くと、アンロードされます。GET10分以上ごとにサービスを実行せずにアプリケーションを継続的に実行する適切な方法に出会ったことはありません。

不適切に設計されたバックエンド/データレイヤーは、何かを実行するのを遅くする可能性があります（それを実行しているコンピューターの速度に関係なく）。プロファイリングは、問題の場所を特定するのに役立ちます。

あなたは間違いなくこれを想像しています。:)

ソフトウェアには多くの要因が関係しています。アーキテクチャ、コードフローの冗長性、コードの品質など。リストし始めるには多すぎます。

ASPがエンタープライズレベルの使用に適しているという証拠が必要ですか？このサイト（およびすべてのSE）のWebサイトは、ASP.Net、特にMVCを使用して作成されています。

このサイトが遅いのはい​​つですか？私はここに1年以上滞在していますが、その膨大なユーザーベースにもかかわらず、物事が進行していることに気づいたことはありません。

ビューステートはポストバックを実際に遅くする可能性があります。ページに大きなドロップダウンリストがいくつかある場合は、それらのビューステートを使用しないでください。

ビューステートを使用すると、ステートフルなwinformsアプリで作業しているように見せかけることができます。それは時々あなたを困らせることができます。

上記のすべてが当てはまる可能性があります。私が取り組んだASP.NETサイトのパフォーマンスに影響を与えた最大の要因は、それに関連するすべてが古いことでした。.NETフレームワークのバージョン、サーバー、データベースインフラストラクチャ、およびコード自体はすべて古くなっていた。

多くのASP.NETサイトは企業サイトである傾向があると思います。彼らはただ働く傾向があるので、これらはあまり愛されません。必要になるまで、人々はそれらを書き直しません。これは、多くの場合、非常に長い道のりです。

私が使用したASP.NETを使用して作業したサイトは、フレームワークの最新バージョンに移行するだけで大幅に高速化されたことがわかります。

ASP.NETサイトの多くが適切にスケーリングする方法を知らないことをもう1つ見ました。コミュニティでは、Webガーデンで正しく動作するようにサイトを設計することは一般的ではなく、十分に文書化されていないため、適切な負荷分散が設定されていません。最初からWebガーデン用にサイトを設計しないと、IISに組み込まれているスケールアウトメカニズムを使用できません。Windows NLBによるソフトウェアの負荷分散はあまり一般的ではなく、管理が複雑です。（これは、ASP.NETが企業ソフトウェアである傾向があり、この構成を正しく構成する方法を知っているIT専門家ではなく、サイトを運営している会社によって管理される傾向があるという事実を思い起こさせます。）

F5を使用したハードウェア負荷分散は非常に高価ですが、企業ネットワーク内のASP.NETサイトをスケールアウトするための最も一般的で単純なメカニズムのようです。オープンソースの群衆の間では、使用量に基づいて自動的にスケールアウトする無料で入手できるオープンソースツールを使用して、最初からロードバランシングを組み込むことが期待されていると思います。これは、ASP.NETの世界では一般的なことではありません。