問題タブ [servicepoint]

これら 2 つの設定 (下記) を調整する必要があるのはいつですか? そして、これらの 2 つの数値は、私が作成したHttpWebRequestインスタンスに対して何を意味するのでしょうか?

1. System.Net.ServicePointManager.DefaultConnectionLimit
2. System.Net.ServicePointManager.MaxServicePointIdleTime

ServicePointオブジェクトはドメイン名または要求されたそれぞれの一意の URI に固有のものですか?

ServicePointManager.DefaultConnectionLimitを変更すると、現在のプロセスまたは.NETプラットフォーム全体にのみ影響しますか。ソースを提供してください。

私は、毎分数百の HTTP 要求をさまざまな URI に送信するアプリケーションを使用しています。アプリケーションが作成した接続を監視する方法はありますか? 特定のドメインを調べるには ServicePointManager が優れていることがわかりましたが、スコープを狭めるには URI が必要です。 ServicePointManagerが現在行われているすべての接続とそれらの同時接続数のリストを公開すれば、私の問題は解決します。

なぜ私はこれをしたいのですか？完了して単純な JSON を返すまでに 30 秒かかるリクエストのタイムアウト例外を診断しようとしています。（タイムアウトはすべてのリクエストで発生するわけではありません）タイムアウトの理由はないようです。ServicePointManager から利用できる 96 を超えたため、利用可能な接続が不足している可能性があります。これが私のボトルネックです。可能性は低いですが、それが今私が思いつくことができる唯一のものです. 提案？

多数のhttp呼び出しを行うサードパーティのライブラリを使用しています。コードを逆コンパイルすることで、rawを作成して使用していることを確認しHttpWebRequest、すべて単一のURLにアクセスします。問題は、一部のリクエストが適切に閉じられないことです。しばらくするHttpWebRequestと、ライブラリがGetRequestStream（）*を呼び出すと、すべての新しいブロックが永久にブロックされます。このブロックは、その特定のホストのServicePointのConnectionLimitによるものであると判断しました。デフォルト値は2です。つまり、ライブラリは2つのリクエストを開いてから、3番目のリクエストを開こうとします。これによりブロックされます。

このブロッキングから保護したいと思います。ライブラリはかなり回復力があり、それ自体を再接続するので、既存の接続を切断しても問題ありません。問題は、このライブラリが作成するHttpWebRequestまたはのいずれにもアクセスできないことです。HttpWebResponseただし、アクセスするURLはわかっているので、にアクセスできますServicePoint。

（注：KeepAliveはこれらのHttpWebRequestsで有効になっています）

C# で記述された ASP.NET 3.5 サーバー アプリケーションがあります。HttpWebRequest と HttpWebResponse を使用して、REST API への送信要求を行います。

これらのリクエストを別々のスレッドで送信するテスト アプリケーションをセットアップしました (サーバーに対する並行性をぼんやりと模倣するため)。

これは、コードに関する質問というよりも、Mono/Environment に関する質問であることに注意してください。したがって、以下のコードは逐語的ではないことに注意してください。機能ビットのカット/ペーストだけです。

ここにいくつかの疑似コードがあります:

Visual Studio Web サーバーのローカル開発マシン (Windows 7) でアプリケーションを実行すると、numThreads を上げて、1 人の「ユーザー」でも 100 人でも、最小限の変動で同じ平均応答時間を得ることができます。

Mono 2.10.2 環境でアプリケーションを Apache2 に公開およびデプロイすると、応答時間はほぼ直線的に変化します。(つまり、1 スレッド = 300 ミリ秒、5 スレッド = 1500 ミリ秒、10 スレッド = 3000 ミリ秒)。これは、サーバー エンドポイント (異なるホスト名、異なるネットワークなど) に関係なく発生します。

IPTRAF (およびその他のネットワーク ツール) を使用すると、アプリケーションがすべての接続をルーティングするために 1 つまたは 2 つのポートのみを開き、残りの応答を待機する必要があるように見えます。

同様の PHP アプリケーションを構築し、同じリクエストを使用して Mono にデプロイしました。レスポンスは適切にスケーリングされます。

Mono と Apache で考えられるすべての構成設定を実行しましたが、2 つの環境間で (少なくともコードで) 唯一異なる設定は、Mono では ServicePoint SupportsPipelining=false であり、私の環境では true である場合があることです。機械。

何らかの理由で ConnectionLimit (デフォルトの 2) が Mono で変更されていないようですが、指定されたホストのコードと web.config の両方でより高い値に設定しています。

私と私のチームが重要なことを見落としているか、これが Mono の何らかのバグであるかのどちらかです。

私はリンクチェッカーに取り組んでいます。通常はHEADリクエストを実行できますが、一部のサイトではこの動詞が無効になっているようです。そのため、失敗した場合はGETリクエストも実行する必要があります (リンクが実際に無効であることを再確認するため)。

リンクテスターとして次のコードを使用します。

これはすべてうまく機能します。GETリクエストを実行すると、ペイロード全体がダウンロードされることを除いて（私はこれをwiresharkで見ました）。

応答本文をバッファリングまたは熱心にロードしないServicePointように、基礎となるものを構成する方法はありますか?HttpWebRequest

(これを手作業でコーディングしていた場合、TCP 受信ウィンドウを非常に低く設定し、ヘッダーを取得するのに十分なパケットのみを取得し、十分な情報が得られたらすぐに TCP パケットの ack を停止します。)

_{これが何を達成しようとしているのか疑問に思っている人のために、404 を取得したときに 40k の 404 をダウンロードしたくありません。これを数十万回行うと、ネットワークに負荷がかかります。}

BindIPEndPointDelegate を使用して HttpWebRequest のソース ポートを変更する方法をあちこちで検索しました。これに関する複数の投稿を見つけました：

こことここ

しかし、それは私のために働いていないようです。この男にも同じ問題が見つかりました: Visual Studio 2010 で SOAP Web サービスの発信/呼び出しポートを定義する

基本的に、Web ページに接続するときにソース ポートを変更したいと考えています。BindIPEndPointDelegate は非常に簡単です。

netstat -n を使用して接続を確認すると、送信元 IP アドレスとして myipaddress:8086、送信先 IP:80 が表示されるはずです。netstat に表示されるのは、指定したポートでループバック (127.0.0.1:8086) を作成していることです。netstat -nのスクリーンショットを見る

初めての投稿なので画像は載せません。というわけで画像はこちらから

BindIPEndPointDelegate がループ バック接続を作成するのはなぜですか? また、指定したポートで WebRequest をブラウザーのように動作させるにはどうすればよいですか?

私はwin7 Proボックスを使用しており、ローカルファイアウォールはなく、プロキシを経由していません。

.net Framework 3.5 では、http 1.1、つまり永続的な接続が使用され、デフォルトでパイプラインが有効になっています。httpresponse.close または stream.close メソッドを呼び出してストリームまたは接続を閉じ、同じインターネット リソースへの別の http 要求の接続を解放する必要があることを教えてください。私の理解では、httpresponse.close または stream.close が呼び出されなくても、httpconnection、つまり servicepoint は別の同時リクエストを処理できるはずです。確認してください。

このバグの解決に取り組んでいます:
https://github.com/openstacknetsdk/openstack.net/issues/333

この問題にはProtocolViolationException、次のメッセージが含まれます。

チャンク エンコーディングのアップロードは、HTTP/1.0 プロトコルではサポートされていません。

502 レスポンス コードを生成する Web リクエストを作成した後、チャンク エンコーディングで POST リクエストを使用する呼び出しを行うことで、問題を確実に再現できることがわかりました。これは、502 応答に続くServicePoint.HttpBehaviour値を持つプロパティにまでさかのぼります。HttpBehaviour.HTTP10

次のハック（catchブロック内）を使用して問題を解決できました。ServicePointこのコードは、失敗したリクエストによって作成されたインスタンスを から「隠し」、次のリクエストのためにServicePointManager新しいインスタンスを強制的に作成します。ServicePoint

質問:

1. なぜ私はこの行動を観察しているのですか?
2. 問題を解決するための非ハッキーな方法は何ですか?