1

次のシナリオを考えてみましょう。サーバー上のプロセスは、ネットワーク接続からのデータを処理するために使用されます。Twisted を使用すると、これが非常に簡単になり、ネットワーク側でプロトコルにspawnProcess簡単に接続できます。ProcessTransport

ただし、ネットワークからのデータが、プロセスが標準入力で読み取りを実行するよりも速く利用できる状況を Twisted がどのように処理するかを判断することはできませんでした。私が見る限り、Twisted のコードはほとんどの場合、未使用のself._bufferデータを格納するために内部バッファー (または類似のもの) を使用します。これは、高速接続 (ローカル ギガビット LAN 経由など) からの同時要求がメイン メモリをいっぱいにし、大量のスワッピングを引き起こし、状況をさらに悪化させる可能性があることを意味しませんか? どうすればこれを防ぐことができますか?

理想的には、内部バッファには上限があります。私が理解しているように、OSのバッファがいっぱいになると、OSのネットワークコードが自動的に接続を停止させたり、パケットのドロップを開始したりして、クライアントの速度を低下させます。(はい、ネットワーク レベルでの DoS は依然として可能ですが、これは別の問題です)。これは、自分で実装する場合にも採用するアプローチです。内部バッファーがいっぱいの場合は、ソケットから読み取らないでください。

サービスは任意のサイズのファイルを処理できる必要があるため、私の場合、最大要求サイズを制限することもオプションではありません。

4

1 に答える 1

5

ソリューションには 2 つの部分があります。

1 つの部分はプロデューサーと呼ばれます。プロデューサーは、データが生成されるオブジェクトです。TCP トランスポートはプロデューサーです。プロデューサーには、いくつかの便利なメソッドがあります:pauseProducingとresumeProducing. pauseProducingトランスポートがネットワークからのデータの読み取りを停止します。 resumeProducing読み取りを再開します。これにより、まだ処理していない無制限の量のデータがメモリ内に蓄積されないようにすることができます。遅れをとり始めたら、トランスポートを一時停止します。追いついたら再開。

もう 1 つの部分はconsumerと呼ばれます。コンシューマーは、データが入るオブジェクトです。TCP トランスポートもコンシューマーです。ただし、あなたのケースにとってさらに重要なのは、子プロセスのトランスポートも消費者です。コンシューマにはいくつかのメソッドがありますが、特に役立つメソッドは次のとおりregisterProducerです。これにより、どのプロデューサー データがそこから来ているかがコンシューマーに通知されます。消費者は、データを処理する能力に応じpauseProducingて呼び出すことができます。resumeProducingトランスポート (TCP またはプロセス) が、プロデューサがデータの送信を要求するのと同じ速さでデータを送信できない場合、プロデューサを一時停止します。追いつくとまた再開します。

プロデューサーとコンシューマーの詳細については、Twisted のドキュメント を参照してください。

于 2012-04-24T17:24:22.340 に答える