1

クライアントが websocket を使用して IIS に接続するアプリケーションがあります。次に IIS は、IPC が実行可能ファイルに接続するためのローカル プロキシを作成します。

したがって、IIS は仲介者のようなものです。

接続が増えると、アーキテクチャ全体が遅くなります。

そのため、どこかにボトルネックがあります。

興味深いのは、CPU が 25% の使用率を超えていないことです。CPU utils に制限を設けていません。

問題は、たとえば100ミリ秒かかっていた関数としてのコードではなく、現在は1000ミリ秒かかっています。これらの機能はネットワークにバインドされていません。簡単な画像変換。また、ロックなどでブロックしているかどうかも確認します。

システムに参加するユーザーが増えるほど、これらの画像変換がより多く発生し、より多くの CPU が使用されるようになります。しかし、ここでも CPU 使用率は変化せず、約 25% のままです。

最も単純な関数の実行も遅くなっているので、使用できる CPU の量にアプリケーション プールに制限があると推測しています。再度 AppPool の設定を確認しましたが、制限はありません。

これについての提案はありますか？

4

2 に答える 2

4

コードまたはシステム設定による CPU アフィニティ設定のように聞こえます。

アプリケーション プールごとにプロセッサ アフィニティを設定 (したがって 1 つのプロセッサに制限) できます。これにより、そのプールで実行されるアプリが 1 つのプロセッサを使用するように効果的に制限されます。これにより、w3wp プロセスが 1 つのプロセッサのみを使用するように制限されるため、クアッド コア CPU を使用している場合は 25% で実行されます。ここでは、IIS 設定を通じてこれを変更する方法の詳細を確認できます: http://www.iis.net/configreference/system.applicationhost/applicationpools/add/cpu

また、タスク マネージャーをチェックして、プロセスを右クリックし、[アフィニティの設定] をクリックして、IIS を 1 つのコアに制限しているかどうかを確認することもできます。

これがお役に立てば幸いです！

于 2013-04-10T23:58:06.087 に答える
2

アプリケーション プール プロセスのプロセス アフィニティを確認できます。それが、25% にとどまっている理由かもしれません。

プロセッサ アフィニティを超えて、リクエストが長時間実行されている場合、IIS が許可する CPU あたりの同時リクエスト数の既定の制限に達している可能性があります (特に統合モードで....12)。クアッド コア CPU での 25% は、アフィニティが問題であることを示唆していますが、そうでない場合は、これも確認できます。ここに関連する回答があります

于 2013-04-11T00:02:10.527 に答える