3

最初に申し訳ありませんが、どこを見ればよいかわかるかもしれません。私は、AjaxControlToolKit を使用してページの束を持つ ASP.net Web アプリを持っています。私の 2 つの環境では、ページのレンダリング速度が大きく異なります。~5 seconds1 つは、2 つのグリッドと多数のコントロールを持つ比較的単純なページをレンダリングするのに非常に時間がかかることです。どこを見ても記事は「SQLをチェックしてください」と言っていますが、SQLパフォーマンスはすべての環境で共通である必要があるため、そうではありません。また、ページが基本的なポストバックを実行しているだけで、SQL が実行されていない場所に絞り込みましたが、それでも問題は再現されています。ユーザーが [すべて選択] をクリックすると、リスト内の一連の項目がチェックされます。私はこれのためにコードビハインドの時間を計測しましたが、それは高速00:00:00.0002178です。

2 つの環境は同じ場所に並んでおり、どちらも IE9 を使用していますが、一方が W2K8 で実行され、もう一方が W7 で実行されています。それが唯一の本当の違いです。W7 では、ページのレンダリングが比較的高速です。

どんなポインタでも大歓迎です。

編集：

デバッグを false に変更すると、プラスの影響がありました。

デバッグ ページ時間 True 0.143363802770544 False 0.0377570798614921

次に、アプリケーションの各コンポーネントを体系的に調べて、SQL、ViewState などの間違いを犯している理由を確認します。興味のある人のために、最終的な調査結果で投稿を更新します。

助けてくれてありがとう！

4

2 に答える 2

1

私は次のことを確認します

  1. タスク マネージャー (Web アプリとデータベース) を使用して、サーバーの CPU 使用率を確認します。極限か

  2. サーバーの物理メモリが不足しています-再びタスクマネージャー

  3. 返されたページは大量ですか。これは明らかですが、そうでない場合もあります。HTML の量が多すぎると、ページが死んでしまう可能性があります。これは非表示 (ViewState、display:'none' の要素) または実際にはページ上にある可能性がありますが、見慣れすぎて見えない場合があります。

  4. それにフィドラーを取得します。すべきではない外部リソースを呼び出していますか。依存している Web サービスが、特定のボックスから突然アクセスできなくなった可能性があります。サイトを完全に停止させるタイムアウトになった Twitter フィードがありました。

  5. データベースをプロファイリングします。あなたはそれができないと思いますが、あなたは確信しています。よろしいですか。同じもの同士を比較して、気付かないうちに 1 つのテストで膨大な量のデータを取得することはないかもしれません。

  6. 特定のプロセスは、ページ/データの長さに非常に敏感です。たとえば、ページが特定のサイズに達すると完全に失敗し、ページがタイムアウトする正規表現がありました。パフォーマンスはほとんど低下しませんでした-完全に停止しました（書き方が悪い-誰がやったのか-えーと！）

  7. 物理的なボックスはちょうど死にかけています。そこに他のプロセス/サイトがあり、それを殺しています。誰とボックスを共有していますか? ハードディスクが外れていませんか？

  8. ファイアウォールは厄介な場合があります。物理ファイアウォールを再起動することで、パフォーマンスが大幅に向上しました。それらのパケットを追跡できますか?

もっとあるでしょう - パフォーマンスのデバッグはちょっとした芸術かもしれません。でもねえ、私たちは皆アーティストですよね。

于 2012-05-03T13:30:26.510 に答える
0

おそらく最初に、web.configで「デバッグ」モードがオンになっているかどうかを確認します

于 2012-05-03T12:53:35.483 に答える