アプリケーション内部のスレッドとサーバーのプロセス

Question

私は、リクエストを処理するのに特に時間がかかることがあります（それは不具合ではありません）。それはほとんど何も処理をしないので、かなり速い99％の時間。

サイトがリクエストを処理するのに時間がかかる場合は、「読み込み中」というメッセージを表示します。私のサイトはmod_wsgiとApacheを使用しています。私はそれを見て、処理を完了する前に「読み込み中」と答えて、直前の2つのうちの1つを実行します：

-spawn処理を担当するスレッド（デーモン）スレッド。

- ソケットを介して他のプロセスと通信し、処理を担当するよう伝えます（おそらくhttp://localhost:8080/do_processingに要求を送信します）。

1つのアプローチと他のアプローチの賛否両論は何ですか？

Answer 1

別のプロセスを使用する方が優れています。 Celery（http://celeryproject.org/）のような既存のシステムをそのまま使うことができるので、別の答えで示唆されているように、難しいことではありません。スレッドの数が吹き飛ばされるのを防ぐために、独自の内部ジョブキューイングシステムを実装しない限り、プロセススレッドに依存することは必ずしも良い考えではありません。また、マルチプロセスサーバー構成では、要求が同じプロセスに戻ってくることを保証できないため、実行中の操作のステータスを取得するのが容易ではありません。最後に、Webサーバーのプロセスが強制終了され、バックグラウンドタスクが終了する前に終了する可能性があります。そのような出来事が残っていればそれを生き延びることができる状態を保つための仕組みが必要です。セロリのようなものを使うのはずっと簡単です。

Answer 2

プロセスルートにはかなりのシステム処理が必要です。別のプロセスの作成は、比較的高価で遅い。ただし、プロセスがクラッシュしても、主な統治プロセスには影響しません（終了ステータスコードが表示され、新しい作業プロセスを再開する機会があります）。 InterProcessCommunicationレイヤー（ソケット、パイプ、共有メモリーなど）も必要です。これは、プロジェクトの複雑さを増すものです。

スレッドは軽量で安価です。共有リソースへの同時アクセスを管理するだけです。だからそれは本当にあなたが念頭に置いている仕事にかかっています。スレッドはおそらく、あなたのタスクを実装するための適切な方法でしょう。