問題タブ [evented-io]

特に、I/O 完了ポートを使用する Asp.NET 4.5 で導入されたResponse.BeginFlushと同様の機能を求めています。

.NET 4 より前のバージョンでは、HttpResponse を使用して非同期 IO を実装するのに十分な公開が行われていないように見えるため、これが不可能になるのではないかと心配しています。IHttpAsyncHanderは、現在公開されている限りです。HttpListener の統合にはあまり希望がないようです。

また、.NET 4.5 に依存していると思われる Asp.NET でSignalRを調べました。

私はどれくらいめちゃくちゃですか？

geventを使用する複雑なPythonプログラムがあります。

私はこの恐ろしい問題を抱えていて、ソケットでのタイムアウトが数分間読み取られました。私はこれらのエピソードの間に何度も再試行し、数分後にのみ成功します。

これらのエピソードの1つで、イベントが発生していない別のプロセスからそのソケットを読み取ることができるため、ソケットをリッスンしている人はまだ完全に機能していると確信しています。

これはgevent1.0で修正されたバグである可能性がありますが、アップグレードは簡単ではありません。1〜2週間のアップグレードを行う前に、geventのソケットが実際に私の問題であると確信したいと思います。

また、プログラムをイベントなしに変更することも簡単ではありません。

geventのソケットに問題があるという仮説をどのようにテストできますか？

私は最近PlayFramework2.0に移行しましたが、コントローラーが実際にPlayでどのように機能するかについていくつか質問があります。

プレイドキュメントには次のように記載されています。

Play 2.0の動作方法により、アクションコードは可能な限り高速である必要があります（つまり、ノンブロッキング）。

ただし、ドキュメントの別の部分では：

と

コントローラーの処理には24のアクターが割り当てられているようです。私は、すべてのリクエストが、リクエストの存続期間中、それらのアクターの1つを割り当てると思います。そうですか？

また、どういうparallelism-factor意味で、どうfork-join-executor違うのthread-poolですか？

また、ドキュメントには、長い計算には非同期を使用する必要があると記載されている必要があります。長い計算と見なされるものは何ですか？100ms？300ms？5秒？10秒？私の推測では1秒以上のことですが、それをどのように判断するのですか？

この質問の理由は、非同期コントローラー呼び出しのテストが通常の呼び出しよりもはるかに難しいためです。メソッドを呼び出してその戻り値をチェックするだけでなく、偽のアプリケーションを起動して本格的なリクエストを実行する必要があります。

そうではなかったとしても、すべてを包み込むことが道であるAsync とAkka.futureは思えません。

#playframework IRCチャンネルでこれを求めましたが、答えがなく、どうすればよいかわからないのは私だけではないようです。

繰り返しになりますが：

1. すべてのリクエストが/actionsプールから1人のアクターを割り当てるのは正しいですか？
2. どういうparallelism-factor意味ですか、なぜそれは1ですか？
3. とどうfork-join-executor違うのthread-pool-executor？
4. 計算がラップされるまでにどのくらいの時間が必要Asyncですか？
5. 偽のアプリケーションを起動せずに非同期コントローラーメソッドをテストすることはできませんか？

前もって感謝します。

編集：IRCからのいくつかのもの

IRCからのいくつかのもの。

関数を使用して libuv でイベント ループを実行する場合uv_run、次の値で使用される「モード」パラメーターがあります。

最初の 2 つは明らかです。UV_RUN_DEFAULTイベントがなくなるまでイベント ループを実行し、UV_RUN_ONCEループから 1 つのイベントを処理します。ただし、UV_RUN_NOWAIT別のモードではなく、他の 2 つの値のいずれかと OR できるフラグのようです。

デフォルトでは、この関数はイベントの処理が完了するまでブロックし、非ブロックにしUV_RUN_NOWAITますが、私が見つけることができるドキュメントはそこで終わります。私の質問は、イベント ループ ノンブロッキングを実行する場合、コールバックはどのように処理されるかということです。

libuv イベント モデルはシングル スレッド (リアクター パターン) であるため、コールバックを呼び出すにはブロックする必要があると思いますが、メイン スレッドが占有されている場合、処理後のイベントはどうなりますか? libuv が再びメイン スレッドの制御を取得するまで、コールバックは「キュー」に入れられますか? または、コールバックは別のスレッドでディスパッチされますか?

そのため、サーバーを介してサードパーティの URL から要求元のクライアントに巨大なファイルをストリーミングしたい状況を実験しています。

これまでのところ、次のように、"eachable" レスポンス ボディの標準的な Rack の慣例に従って、Curb または Net::HTTP でこれを実装しようとしました。

ただし、このシステムの CPU 使用率を 40% 未満にすることはできません (私の MacBook Air では)。Goliath で同じことをしようとすると、em-synchrony を使用して (Goliath ページでアドバイスされているように)、CPU 使用率を約 25% の CPU に下げることができますが、ヘッダーをフラッシュすることはできません。要求しているクライアントでストリーミング ダウンロードが「ハング」し、指定したヘッダーに関係なく、応答全体がクライアントに送信されるとヘッダーが表示されます。

これは、Ruby が驚くほどうまくいかず、代わりに世界の go と nodejs に目を向けなければならないケースの 1 つであると考えるのは正しいでしょうか?

比較すると、現在、CURL から PHP 出力ストリームへの PHP ストリーミングを使用しており、CPU オーバーヘッドはほとんどありません。

または、自分のものを処理するよう依頼できるアップストリーム プロキシ ソリューションはありますか? 問題は - 本体全体がソケットに送信されたら Ruby 関数を確実に呼び出したいのですが、nginx プロキシなどではそれができません。

更新: HTTP クライアントの簡単なベンチマークを実行しようとしましたが、ほとんどの CPU 使用は HTTP クライアント ライブラリのようです。Ruby HTTP クライアントのベンチマークがありますが、それらは応答受信時間に基づいていますが、CPU 使用率については言及されていません。私のテストでは、結果を に書き込む HTTP ストリーミング ダウンロードを実行し、/dev/null一貫して 30 ～ 40% の CPU 使用率を得ました。これは、Rack ハンドラを介してストリーミングしたときの CPU 使用率とほぼ一致します。

更新:ほとんどの Rack ハンドラー (Unicorn など) は、応答本文で write() ループを使用することが判明しました。これは、応答を十分に高速に書き込むことができない場合に (CPU 負荷が高い) ビジー状態になる可能性があります。これは、を使用して出力ソケットに書き込みを行うことで、ある程度軽減できます(rack.hijackサーバーが自分でそれを行わないことに驚きました)。write_nonblockIO.select

スレッド化されたサーバー (現在 MRI で実行中) のソケットに書き込みを行っています。次のコードでそれを行います：

その要点は、WaitWritable を取得した場合 (ソケットが飽和している場合)、これを実行するサーバーに別のスレッドを先取りさせたいということです。ここで良い考えですかThread.pass、または私のスレッドが実行している場合、MRI は自動的に何か他のものをプリエンプトしますselect()か?