ruby - ネットワーク リクエストを作成するとき、いつスレッドとプロセスを使用する必要がありますか?

Question

私は、open-uriさまざまな API に対して ( 経由で) 何百ものネットワーク リクエストを行う Ruby スクリプトに取り組んでいます。

Thread私はこれを使用するか、これを達成することを検討してきましProcessたが、どの方法を使用すればよいかわかりません。

ネットワーク リクエストに関して、いつThreadover を使用する必要Processがありますか、それとも問題ではありませんか?

Answer 1

詳細に入る前に、問題を解決するライブラリが既にあります。Typhoeusは、多数の HTTP リクエストを並行して実行するように最適化されており、libcurl ライブラリに基づいています。

100 個の蛇の頭を持つ神話上の獣の最新のコード バージョンのように、Typhoeusは処理ロジックをきれいにカプセル化しながら HTTP リクエストを並行して実行します。

スレッドは、アプリケーションと同じプロセスで実行されます。Ruby 1.9 以降、ネイティブ スレッドが基になる実装として使用されます。すべてのスレッドがアプリケーションの相互状態にアクセスできるため、スレッド間でリソースを簡単に共有できます。ただし、問題は、ほとんどの Ruby 実装で CPU の複数のコアを利用できないことです。

Ruby は Global Interpreter Lock (GIL) を使用します。GIL は、異なるスレッドからの並列変更が原因で相互の状態が破損しないようにするためのロック メカニズムです。JRuby、Rubinius、MacRuby などの他の Ruby 実装は、GIL を使用しないアプローチを提供します。

プロセスは互いに別々に実行されます。プロセスはリソースを共有しません。つまり、すべてのプロセスには独自の状態があります。リクエスト間でデータを共有したい場合、これは問題になる可能性があります。プロセスは、独自のメモリ スタックも割り当てます。RabitMQ のようなメッセージング バスを使用してデータを共有することもできます。

スレッドのみ、またはプロセスのみを使用することはお勧めできません。自分で実装したい場合は、両方を使用する必要があります。nごとに fork を 実行すると、新しいプロセスが要求され、その後、HTTP 要求を発行するために多数のスレッドが再び生成されます。なんで？

HTTP リクエストごとに別のプロセスをフォークすると、プロセスが多すぎます。オペレーティング システムはこれを処理できるかもしれませんが、オーバーヘッドは依然として途方もないものです。一部の HTTP リクエストは非常に高速に終了する可能性があるため、余分なプロセスを気にする必要はありません。別のスレッドでそれらを実行してください。