0

Google App Engine にプル キューがあり、プル キュー内のタスクを処理する常駐バックエンドがあります。Google Cloud Platform ブログの投稿で提案されているように、バックエンドには、タスクを消費して処理するための複数のワーカー スレッドがあります。

https://cloud.google.com/resources/articles/ios-push-notifications

ワーカーは、lease_tasks() でプル キューをポーリングします。私の質問は次のとおりです: lease_tasks() はブロッキング メソッドであるはずですか。つまり、キューにいくつかのタスクがあるか、期限を超えるまで現在のスレッドの実行をブロックしますか?

GAEのドキュメントによると

https://developers.google.com/appengine/docs/python/taskqueue/overview-pull#Python_Leasing_tasks

lease_tasks() は「deadline」パラメーターを受け入れ、DeadlineExceededError を発生させる可能性があるため、leas_tasks() が「deadline」秒までブロックすると仮定するのは合理的ではありませんか?

問題は、開発サーバーでアプリケーションを開発しているときに、lease_tasks() がすぐにタスクの空のリストを返すことです。その結果、ワーカー スレッドの while ループは常に lease_tasks() を呼び出し、CPU を 100% 消費します。たとえば 5 秒間、明示的な sleep() を設定すると、ワーカーはスリープ状態になり、その間にタスクがキューに配置されても起動しません。これにより、ワーカーの応答性が低下し (最悪の場合、次のタスクの処理に 5 秒以上かかる場合があります)、スレッド ブロックを「キュー」に入れるよりも多くの CPU を消費します (ウェイク アップ -> スリープ サイクル)。 (プルキューが実際にはRPCであることは知っていますが、抽象的にはプロデューサーキューのままです)

おそらく、これは、GAE lease_tasks() ブロック内で開発アプリ サーバーでのみ発生します。ただし、上記のブログ投稿のサンプル コードでも、sleep() を使用してスレッドの実行を一時停止しています。サンプル コードは github で入手でき、リンクはブログ投稿にあります (残念ながら、ここに投稿することはできません)。

4

1 に答える 1