2

ネットワークアプリケーションの1つで遅延の問題が発生しています。ほとんどの場合、リクエストは100ミリ秒以内に処理されます。ただし、明確な理由がない場合は、最大で数秒かかる場合があります。

そこで、いくつかの監視ツールを接続して、何が起こっているかを調べました(Wiresharkはポートレプリケーションを介して外部でネットワークを監視し、Process Monitorはローカルマシンで何が起こっているかを確認します)。

私はtcpパケットを一致させることができました、そしてそれらは通常両方のログファイルでお互いのミリ秒以内にあります。しかし、ある発生では、シリーズの最後のパケットは、wiresharkと比較してProcess Monitorで250ms以上遅延しました(そして、遅延によるアプリケーションの不安定な動作が観察されていました)。

Wiresharkが別のコンピューターに接続されていたので、監視されていたものが正確であると確信しています。パックされたものはすべて、時間どおりにネットワークカードに到達しました。プロセスモニターに関しては、それがどのように機能するか完全にはわかりません。ネットワークデータはいつ登録されますか?ネットワークカードに届いたときですか?アプリケーションで利用できるようになるのはいつですか?アプリケーションがデータを読み取るときは?

これらの250ミリ秒の間に、他にもいくつかのイベントが登録されていたため、Process Monitorは正しく記録されており、この250ミリ秒の遅延はそれによって「作成」されなかったと思います。

プロセスモニターの動作、問題を掘り下げるために私が使用している現在の方法、または問題である可能性があると思われることに関するヘルプをいただければ幸いです。

4

1 に答える 1

1

オプション 2

おそらく、GC が時々引き起こす悪名高い 250 ミリ秒の遅延を経験しているかもしれません (リンク)。専用の CLR ホストを使用して GC 懸濁液を正確に測定できます (リンク)

オプション 1 - 除外されました

TCP を使用しているため、ソケットのNoDelayオプションをオンにして、Nagle のアルゴリズムと遅延 ACK アルゴリズムの衝突が発生する可能性を排除することをお勧めします。パケットの「バッチ処理」が発生し、パケットが約 200 ミリ秒「遅延」することがある場合は、それが問題である可能性があります。
この動作の詳細については、こちらを参照してください。

于 2010-09-25T18:23:30.323 に答える