大きな負荷がかかるサーバー アプリケーションのパフォーマンスのボトルネックを見つける必要があります。アプリケーションは、単一のサービス インスタンス (.asmx) と、時々 http 経由で要求されるいくつかのファイルで構成されます。この問題を解決するための私の計画は、1) サーバーが何らかの理由で失敗し始めたときに例外的な状況に陥ることです。2) その瞬間のパフォーマンス カウンターとログを分析して、その原因となった呼び出しの種類を推測します。
これを達成するために、両方のタイプのリクエストを発行する特別なクライアントを実装し、WebMethod/GET URL リクエスト中にエラーが発生することを期待して、それぞれのサイクルを無期限に繰り返すようにしました (NB - JMeter や WAPT などの標準の既存のソリューションサービスの使用シナリオが複雑なため、使用できません)。これまでのところ、私が観察しているのは、サービス呼び出しの応答時間の増加と、ファイルの読み込み中のネットワークタイムアウト例外です (このスレッドに従ってタイムアウトと見なされる OperationCanceledException をスローする HttpClient を使用)。ファイルのサイズは数 KB であり、サービス メソッドは要求ごとに 5 ～ 10 MB のデータを返すため、これは奇妙です。「より大きな」リクエストは、最初に失敗する可能性が高いと考えられていました。
Perfmon は、CPU 負荷の増加を示し、メモリのスパイクやリークはまったくありません。Request Execution Time カウンターはかなりランダムで無関係に見えます。Queue Length は常に 0
です。とはいえ、IIS は即席の DDoS を適切に処理し、同時にテスト アプローチを無効にしているようです (応答時間が長くなると、テスト クライアントのメモリ内のアクティブな要求が増えることを意味します)。これにより、ある時点でメモリオーバーフローが発生し、データを受け取った直後に何もせずにすでにデータをフラッシュしています)。
詳細 : サーバー マシンは 4x3Ghz コア、4 Gb RAM です。毎秒 50 ～ 100 リクエストの負荷を生成すると、帯域幅は 10 ～ 20 Mb/秒になります (テスト クライアントは、サーバーのデータセンター内の VM、4 Gbps NIC に配置されます)。30 分間のテスト セッションは、サーバーとクライアント間の 10 ～ 30 Gb の純粋なデータ転送です。
Web サービス/IIS を実際にダウンさせるにはどうすればよいですか?