私の Google App Engine アプリケーションは、大量の遅延タスクをタスク キューに追加しています。タスクは x 秒ごとに実行されるようにスケジュールされています。バケットサイズ プロパティbを正しく理解していれば、値が大きいと、 b個のタスクが追加されるまで、延期されたタスクが実行されなくなります。ただし、タスクがスケジュールどおりに実行されるというほぼリアルタイムの要件があります。バケットサイズに達するまでタスクがブロックされるのは望ましくありません。代わりに、スケジュールされた時間にできるだけ近く実行する必要があります。
このユースケースをサポートするには、バケットサイズ1 とレート500 (現在の最大レート) を使用する必要がありますか? これをサポートするために他にどのようなアプローチがありますか? ありがとう！
バケット サイズによって、タスクが個別に実行されなくなることはありません。それは別の役割を果たします。
1 秒あたり 500 タスクの速度で空のキューがあり、数時間タスクが追加または開始されていないとします。すると突然、大量のタスクが一度に追加されます。これらのタスクのうち、すぐに開始したいタスクはいくつありますか? この数値をバケット サイズとして設定します。たとえば、バケット サイズが 1000 の場合、1000 のタスクがすぐに開始されます (その後、毎秒 500 のタスクが開始されます)。
これはどのように作動しますか？バケットは、毎秒 500 トークン (キューのレート) で補充され、最大値はバケット サイズです。開始できるタスクがある場合、それらはバケットが空でないときにのみ開始され、各タスクが開始されるたびにバケットから 1 つのトークンが削除されます。
バケット/レート設定が高いスループットを保証するという仮定を使用して、ほぼリアルタイムで実行することが重要な遅延タスクにタスクキュー (TQ) を使用しないでください。Google グループには、タスクの開始時間が数分以上かかるまれな遅延について、いくつかのディスカッション スレッドがありました。バケットのサイズとレートはこれに影響しません。高スループット TQ がアイドル状態の間、TQ タスクはそこに留まります。これまでのところ、なぜこのようなことが起こるのかについて、Google からの説明は見たことがありません。繰り返しになりますが、ほぼリアルタイムのタスクに TQ を使用する場合は、タスクが開始前に数分間遅延するまれな時間を例外として処理する必要があります。（私は実際にこれを行っており、まだ悪影響を受けていませんが、結果を処理するためのコードを配置する必要があります=遅延タスク）。