長時間実行されているがCPUタスクが少ない、またはロングポーリングのためのGoogle App Engine？

Question

App Engineは、データベースやキャッシュやサードパーティのリソースへの外部API呼び出しを行わずにすばやく処理するリクエストに最適ですが、「長期実行」コンポーネントや外部レイテンシを導入すると、 HTTP POST操作はバックグラウンドで非同期で実行され、さらに強力なデータベースクエリを処理するには2〜3秒かかります。非同期ですが、それ以来、クライアント側のUXの観点からはOKですそれは長時間走っています）... "インスタンス時間"の化合物とドライブはかなりコストがかかります。

要求が文字通り外部リソースからの応答を待っており、アイドリング時にCPUをほとんど必要としないこのような状況は、と思われますが、App Engineで回避できないかどうかはわかりません。

これは、応答が開いたままだが何もしない「長い投票」のようなものです。

App Engineでこれを実行する方法はありますか？インスタンス時間に驚異的な金額を支払うだけでなく、Compute EngineまたはEC2に移行する方がよいでしょうか？それはCPUの負荷に基づいて自動的に拡張されるのですか、またはそれは総数の中で開いている要求とおそらくは非アクティブな要求だけに基づいていますか？ - threadsafeが有効です。

Answer 1

これについては、実際には2つの方法があります。

タスクキューを使用してください！

作業が要求と同時に正確になる必要がない場合、これはまさにApp Engineの[タスクキュー]と同じものです。それらを使用すると、ジョブをキューに入れて、別のモジュールで作業を取り上げることができます。フロントエンドプロセスとバックエンドプロセスを個別に拡張することができます。

それはボンネットの下にApp Engine Flexible ....

使用App Engineの柔軟な

動作しない場合は、単にGCEインスタンスを実行しています。コスト構造はまったく異なります。バックグラウンドで実行しているVMが永続的に要求を処理するからです。

希望すると便利です。

Answer 2

ここで本当に心配しているのは、App Engine scalesのインスタンスの仕組みです。多くのリクエストではリソースがほとんど必要ないため、アプリは通常よりも多くの同時リクエストを1つのインスタンスで処理できる可能性があります。スケーリングを形作るパラメータを調べることができますhere。

max_concurrent_requestsスケジューラは、新しいインスタンス生成します前に、自動スケーリングのインスタンスが受け入れることができる同時要求の数（デフォルト：最大8、：80）特に興味深いの。

ここでは、インスタンスが長時間のポーリング要求で満たされ、過負荷になる危険性があります。これを防ぐには、長いポーリングリクエストを独自のserviceに分離し、スケーリングパラメータを他のアプリとは別に設定することができます。