2011-10-19 4 views
8

私はクライアント/サーバーアプリケーションを持っています。サーバーコンポーネントが実行され、WCFが「リモーティング」形式(バイナリフォーマッタ、セッションオブジェクト)で使用されます。C#コードが非常に遅く、デバッガが接続されています。 MemoryMappedFileのフォルト?

サーバコンポーネントを起動してクライアントを起動すると、サーバが最初に行う作業は<で完了します。

VSデバッガを接続してサーバーコンポーネントを起動してからクライアントを起動すると、タスクの完了に20秒以上かかることがあります。

コードの変更はありません。条件付きコンパイルの変更はありません。同じことが、VSホスティングプロセスなしで、VSホスティングプロセスなしで、またはこれらのものの任意の組み合わせで、32ビット、64ビットでコンパイルされ、実行されているサーバーコンポーネントがあるかどうかに関係なく発生します。

おそらく重要:私はVS.NET プロファイラ(サンプリングモード)を使用すると、アプリが添付何デバッガがなかったかのよう迅速に実行されます。だから私はそれをそのように診断することはできません。ちょうどチェックされると、計装モードも迅速に実行されます。同時実行プロファイリングモードと同じですが、すぐに動作します。

キーデータ:

  • アプリはかなり重いマルチスレッディング(標準スレッドプール内の40スレッド)を使用しています。スレッドを作成することは、遅くなくても迅速に行われます。多くのロック、WaitHandlesとMonitorのパターン
  • アプリは全く例外を発生させません。
  • アプリケーションはコンソール出力を作成しません。
  • アプリは完全に管理されたコードです。 1x750MBと12x8MBといくつかの小さなもの

測定された性能:

  • アプリはメモリマップトファイルをディスク上のいくつかのファイルをマップしない

    • CPUの使用は、どちらの場合も最小限です。デバッガが接続されている場合、CPUは<に位置します。1%
    • どちらの場合でもメモリ使用量は最小です。おそらくは両方とも50または60MBです
    • ページフォールトが多発していますが(ref MMF)、デバッガが接続されていると遅くなります。
    • VSホスティングプロセスが使用されていない場合、または基本的に 'リモートデバッグモニター 'が作動すると、は、が適量のCPUを使用し、多数のページフォルトを作成します。しかし、問題が発生するのは唯一の問題ではありません。
    • クライアントの実行方法に関係なく、パフォーマンスの差が見られます。変更される唯一の変数は、エクスプローラから起動された 'Start with debugging'を介して実行されるサーバーコンポーネントです。

    私のアイデア:デバッグ時に

    • WCFは遅いですか?
    • デバッグ時にMemoryMappedFilesが遅くなりますか?
    • 40スレッドが使用されました - デバッグが遅くなりましたか?おそらく、モニタ/ロックがデバッガに通知しますか?スレッドスケジューリングが奇妙な/コンテキストスイッチは非常にまれになる? VS

    すべてに知性とユーモアの残酷な感覚を付与

  • 宇宙背景放射は愚かそうに見えます。

    だから、私の質問:

    1. なぜこの出来事はありますか?
    2. #1が不明な場合は、どうすれば診断できますか?
  • +1

    第1回目の例外キャッチを有効にしましたか?また、.NET Server Source Steppingを有効にして、デバッグモード(特にソース解除の例外)で、潜在的な「隠された」例外を最大限にキャッチするようにすることもできます。また、トレース(outputdebugstringやその他)はどうですか? –

    +0

    はい、例外は一切発生しません。第1回目のチャンスとして有効にされたすべてのカテゴリの例外(.NETを含む)。デバッグコンソール出力はありません(これはコンソール出力の意味です - 明確にするために編集します)。私は.NET Framework Source Stepping(Server Source Steppingを見ることができませんでした)を有効にしました。いくつかの例外が見つかりました。瞬時に更新されます –

    +0

    WCFからの例外: "''文字は16進値0x20です。名前に含めることはできません。"私は、例外がこのように隠されるという考えはありませんでした。例外ではないのですか?私は解決するために何ができるかを見ます。おそらくあなたは答えを投稿することができますので、いくつかのアップフォートを得ることができます/これが解決すれば受け入れますか? :) –

    答えて

    9

    例外は、特にアプリケーションのパフォーマンスに影響を与える可能性があります。 1つ目のチャンス例外(try/catchブロックで正常に処理された例外)と未処理の例外(最終的にアプリケーションがクラッシュする)の2種類があります。

    デフォルトでは、デバッガは1stチャンス例外を表示せず、処理されない例外を表示します。また、デフォルトでは、コード内で発生する例外だけが表示されます。しかし、それが表示されない場合でも、それらを処理するので、パフォーマンスが影響を受ける可能性があります(特に負荷テストや大きなループ実行時)。

    Visual Studioで1回目のチャンス例外を有効にするには、[例外|例外]をクリックして例外ダイアログを開き、[共通言語ランタイム]セクションの[スロー]をチェックします(具体的には、あなたが見たいチャンスの例外)。

    "Tools | Options | Debugging | General"をクリックし、 "Enable Just My Code"オプションを無効にして、コード内だけでなく、アプリケーション内のどこからでも最初の例外を表示することができます。

    これらの特定の「フォレンジックモード」の場合、.NET Frameworkのソースステッピングを有効にすることを強くお勧めします(「自分のコードを有効にする」を無効にする必要があります)。それは、時々だけコールスタックを見ていることは非常に刺激的である何が起こっているかを理解することは非常に便利です - 特に:-)宇宙放射線の重複が整理の場合には、有用

    二つの関連する興味深い記事:

    +1

    「.NET Framework Source Stepping」を有効にするまで、他のコメントと同様、例外は完全に「非表示」でした。 'SerializationInfo.SetValue()'が有効なXML要素名ではない 'string'パラメータについて例外をスローするエラーがありました。これは動作し続けますが、さらにNetTcpBinding(バイナリフォーマッタ)を使用していました。 。 –

    2

    これは、この問題のためにグーグルとき、私は私のような研究の誰か2時間を節約することを希望してここに私の問題の解決策を追加したい最初の結果の一つであるので、私の場合。

    デバッガを使用しないでデバッガを4分間接続すると、コードが30秒から遅くなりました。私は条件付きブレークポイントを削除するのを忘れていたからです。これらは実行を大幅に遅らせるようですので、注意してください。

    関連する問題