12

Visual Studio 2010 と Mono Develop 2.8 の両方で C# サーバーを開発しました。NET フレームワーク 4.0

このサーバーは、Linux よりも Windows の方が (スケーラビリティの点で) 動作がはるかに優れているようです。Apache の ab ツールを使用して、ネイティブ Windows (12 物理コア)、および 8 コアと 12 コアの Windows および Ubuntu 仮想マシンでサーバーのスケーラビリティをテストしました。

Windows の応答時間はほぼ一定です。同時実行レベルがコア数に近づく/超えると、回復し始めます。

何らかの理由で、Linux の応答時間が大幅に遅くなります。それらは、並行性のレベル 5 からほぼ直線的に増加します。また、8 コアおよび 12 コアの Linux VM も同様に動作します。

私の質問は、Linux でのパフォーマンスが悪いのはなぜですか? （そしてどうすれば修正できますか？）。

添付のグラフを見てください。リクエストの同時実行数の関数として、リクエストの 75% を満たす平均時間を示しています (範囲バーは 50% と 100% に設定されています)。 リクエストの同時実行数の関数として、リクエストの 75% を満たすまでの時間

これは mono の Garbage Collector が原因ではないかと感じています。GC設定をいじってみましたが、成功しませんでした。なにか提案を？

追加の背景情報: サーバーは、リクエストをすばやく解析してスレッド プールのキューに入れる HTTP リスナーに基づいています。スレッド プールは、集中的な計算 (約 10 秒で回答を計算) を使用して、これらの要求に応答します。

4

6 に答える 6

4

問題がどこにあるかを最初に特定する必要があります。HeapShotでメモリ使用量を監視することから始めます。メモリでない場合は、コードをプロファイリングして、時間のかかるメソッドを特定します。

このページ、Performance Tips: Writing better performance .NET and Mono applicationsには、mono プロファイラーの使用など、いくつかの役立つ情報が含まれています。

過度の文字列操作とボックス化は、多くの場合、うまくスケーリングできないコードの「隠れた」犯人です。

于 2012-05-18T23:47:35.777 に答える
1

これは、スレッドプールと新しいスレッドの開始動作、およびsetMinThreadsのモノラル実装のバグに関連して追跡したのと同じ問題である可能性があると思います。詳細については、そのスレッドに関する私の回答を参照してください：https ://stackoverflow.com/a/12371795/1663096

于 2012-10-29T04:11:16.233 に答える
1

sgen ガベージ コレクターを試してください (そのためには、Mono 2.11.x をお勧めします)。詳細については、mono の man ページを参照してください。

于 2012-05-21T02:13:10.410 に答える
1

GCのせいではないと思います。私の知る限り、GC の副作用はスレッド全体に多かれ少なかれ均等に分散されるはずです。

私の盲目的な推測は、ThreadPool.SetMinThreads/SetMaxThreads API で遊ぶことで修正できるということです。

于 2012-05-21T02:27:56.590 に答える
1

個々のメソッドの実行時間に関して、コードでいくつかのプロファイルを作成することを強くお勧めします。モノによって完全に処理されていない、ロックまたは同様のマルチスレッドの問題が発生している可能性が非常に高いです。CPU と RAM の使用率も役立ちます。

于 2012-05-21T02:51:59.607 に答える
0

コードが多くの例外をスローする場合、mono は .NET よりも 10 倍高速です

于 2012-05-21T02:31:27.190 に答える