研究で何に焦点を当てるべきかについてのガイドに役立つので、これについていくつかの意見をお願いします（スレッドをまったく考慮する必要がある場合）。
スレッドが絶対に必要で、複数プロセス モデルでは適切なソリューションを提供できない Rails アプリケーションの例はありますか。1 つの例外は、メモリ制限があり、複数のプロセスを生成する代わりにスレッドを使用する必要があるアプリケーションです。しかし、メモリが問題ではないと仮定すると、スレッドの方が適しているその他のケースにはどのようなものがありますか?
スレッドは、書き込みとデバッグが容易です。単純なスレッド化されていないコードから始めてデバッグし、最後にThread.newandでチャンクをラップして完了です。join
そして、はい、それらを研究してください。役に立つテクニックを学び、「プログラミング ツールチェスト」に入れておくと役立つ知識を得ることができます。
プロセスができないことでスレッドができることは何ですか? スレッドは非常に簡単にデータを共有し、同じキューから作業できます。別々のプロセスでこれを行うには、データベースや IPC、またはメッセージング キューを使用する必要があり、これらすべてが複雑さを増します (ただし、容量も増加します)。
一般に、スレッドはプロセスよりも作成/破棄が効率的です。
SideKiqはResqueよりも効率的です。これは主に、SideKiq ワーカーがスレッドであるのに対し、Resque はフォークされたワーカー (プロセス) を使用するためです。
しかし問題は、Ruby on MRI にはネイティブ スレッドがないことです。そのため、Ruby の各スレッドは Global Interpreter Lock (GIL) によって制限されます。詳細については、Igvita の記事を参照してください: http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/
JRuby などのネイティブ スレッドを備えたプラットフォームでは、(サーブレット コンテナーで実行されている) マルチスレッドの Rails アプリを使用でき、MRI で実行されている同じアプリよりもパフォーマンスが優れている可能性があります。また、Hotspot JVM 上の JRuby がジャストインタイムのパフォーマンス最適化を実行できる可能性もあります。