ユーザー入力から画像を作成する Web アプリがあります。イメージの作成には数秒かかる場合があります。
リクエスト/レスポンスを処理しているサーバースレッドに画像も生成させると、スレッドが数秒間拘束され、サーバーが停止し、パフォーマンスに影響を与えたり、子犬を殺したりする可能性があります.
Celeryなどのタスク キューを使用して、サーバーがイメージの作成をハンドオフし、要求/応答の処理に戻ることができるようにする必要がありますか? 画像を作成しているユーザーを待たせても問題ありませんが、サイトへの他のユーザーのアクセスに影響を与えたくありません。
いいえと言うつもりです - 今のところ。
そのため、最初は単純にして機能させますが、後でタスク キューを追加する可能性があることに注意してください。
スケーリングが必要な場合は、そのタスク キューを実装します。
経験則: タスクが山積みになる可能性がある場合は、キューを使用します。
あなたの場合、タスクには最大2 秒かかる可能性があり、1 日 8 時間とすると、同時実行なしで 1 日最大 8*60*60/2 = 14400 の画像を実行できます。1 日に 7200 を超えるリクエストを受け取った場合、それらのいずれかが重複する可能性は 50% です。予想されるオーバーラップのレベルを示す、より高度な分析があります。しかし、過負荷になる前に、1 日に 1000 枚以上の画像を処理できると言っても過言ではありません。
質問は簡単に思えます: 近い将来、1 日に 1,000 枚または 2 枚以上の画像が作成されると思いますか? その場合は、キューを設定します。そうでない場合は、後でそのままにしておきます。
いずれにせよ、適切なログを保持してください。処理の重複がいつ発生するかを確認できるようにしてください。2 つのタスクを同時に処理すると時間がかかり、残りの 2 つを完了する前に 3 つ目のタスクが到着する可能性が高くなり、4 つ目のタスクが目に見えないしきい値に達すると、パフォーマンスが大幅に低下することに注意してください。これで寝不足にならないように気をつけてください。
私は画像生成サイト ( Names4Frames ) も持っており、AJAX (および PHP) を介してこのようなことを行いました。目立った速度低下 (または死んだ子犬) はありませんでしたが、問題のサイトは大量のトラフィックを生成していません. 私はスレッドの専門家ではありません。正直に言うと、あなたの正確な懸念事項と使用しているテクノロジーについて 100% 確信が持てません...
基本的に、あるページが別のページ (おそらく別のサーバー上にある場合もある) から画像を要求し、それが完了すると、2 番目のページは処理/表示の目的で画像に関する関連情報を最初のページに返します。この画像作成サービスを常に使用している膨大な量の訪問者を扱っていない限り、数秒しか話していない場合、それが実際の問題であるとは思えません.