私はクライアント/サーバーアプリケーションを持っています。サーバーコンポーネントが実行され、WCFが「リモーティング」形式(バイナリフォーマッタ、セッションオブジェクト)で使用されます。C#コードが非常に遅く、デバッガが接続されています。 MemoryMappedFileのフォルト?
サーバコンポーネントを起動してクライアントを起動すると、サーバが最初に行う作業は<で完了します。
VSデバッガを接続してサーバーコンポーネントを起動してからクライアントを起動すると、タスクの完了に20秒以上かかることがあります。
コードの変更はありません。条件付きコンパイルの変更はありません。同じことが、VSホスティングプロセスなしで、VSホスティングプロセスなしで、またはこれらのものの任意の組み合わせで、32ビット、64ビットでコンパイルされ、実行されているサーバーコンポーネントがあるかどうかに関係なく発生します。
おそらく重要:私はVS.NET プロファイラ(サンプリングモード)を使用すると、アプリが添付何デバッガがなかったかのよう迅速に実行されます。だから私はそれをそのように診断することはできません。ちょうどチェックされると、計装モードも迅速に実行されます。同時実行プロファイリングモードと同じですが、すぐに動作します。
キーデータ:
- アプリはかなり重いマルチスレッディング(標準スレッドプール内の40スレッド)を使用しています。スレッドを作成することは、遅くなくても迅速に行われます。多くのロック、
WaitHandle
sとMonitor
のパターン - アプリは全く例外を発生させません。
- アプリケーションはコンソール出力を作成しません。
- アプリは完全に管理されたコードです。 1x750MBと12x8MBといくつかの小さなもの
測定された性能:
- CPUの使用は、どちらの場合も最小限です。デバッガが接続されている場合、CPUは<に位置します。1%
- どちらの場合でもメモリ使用量は最小です。おそらくは両方とも50または60MBです
- ページフォールトが多発していますが(ref MMF)、デバッガが接続されていると遅くなります。
- VSホスティングプロセスが使用されていない場合、または基本的に 'リモートデバッグモニター 'が作動すると、は、が適量のCPUを使用し、多数のページフォルトを作成します。しかし、問題が発生するのは唯一の問題ではありません。
- クライアントの実行方法に関係なく、パフォーマンスの差が見られます。変更される唯一の変数は、エクスプローラから起動された 'Start with debugging'を介して実行されるサーバーコンポーネントです。
私のアイデア:デバッグ時に
- WCFは遅いですか?
- デバッグ時にMemoryMappedFilesが遅くなりますか?
- 40スレッドが使用されました - デバッグが遅くなりましたか?おそらく、モニタ/ロックがデバッガに通知しますか?スレッドスケジューリングが奇妙な/コンテキストスイッチは非常にまれになる? VS
すべてに知性とユーモアの残酷な感覚を付与
だから、私の質問:
- なぜこの出来事はありますか?
- #1が不明な場合は、どうすれば診断できますか?
第1回目の例外キャッチを有効にしましたか?また、.NET Server Source Steppingを有効にして、デバッグモード(特にソース解除の例外)で、潜在的な「隠された」例外を最大限にキャッチするようにすることもできます。また、トレース(outputdebugstringやその他)はどうですか? –
はい、例外は一切発生しません。第1回目のチャンスとして有効にされたすべてのカテゴリの例外(.NETを含む)。デバッグコンソール出力はありません(これはコンソール出力の意味です - 明確にするために編集します)。私は.NET Framework Source Stepping(Server Source Steppingを見ることができませんでした)を有効にしました。いくつかの例外が見つかりました。瞬時に更新されます –
WCFからの例外: "''文字は16進値0x20です。名前に含めることはできません。"私は、例外がこのように隠されるという考えはありませんでした。例外ではないのですか?私は解決するために何ができるかを見ます。おそらくあなたは答えを投稿することができますので、いくつかのアップフォートを得ることができます/これが解決すれば受け入れますか? :) –