ログに示されているように、リクエストの読み込みが原因でレイテンシの急上昇（リクエストが戻るまでに最大10秒かかる）が発生した低負荷のアプリケーションがあります。
このリクエストにより、アプリケーションの新しいプロセスが開始され、アプリケーションコードが初めてロードされました。
ここで、「新しいプロセス」は「新しいインスタンス」を意味すると仮定します。
これを回避するために、アイドル状態のインスタンスの数を正確に1つ（max=1およびmin=1）に固定しました。これにより、常に1つのインスタンスが実行され（「常駐インスタンス」）、GAEは新しいインスタンスを開始しないようにします。請求が有効になっています。
ただし、リクエストの読み込みはまだ発生しています。なんで？これについて何かできることはありますか？
アイドルインスタンスは「リザーブ」インスタンスです。「通常の」トラフィックではなく、トラフィックが増加したときにスパイクを処理することを目的としています。アイドルインスタンスは、動的インスタンスのスピンアップ中にのみ使用されます。
したがって、アイドル状態のインスタンスが1つあり、動的インスタンスが実行されておらず、リクエストを受け取った場合、アイドル状態のインスタンスがリクエストを処理する必要がありますが、新しいダイナミックインスタンスは引き続き起動されます。
私もトラフィックの少ないアプリで同じ問題を経験しました。これは、ほとんどの場合、ユーザーがコールドスタートに直面するのを防ぐ実用的なソリューションです。-1つの常駐F4インスタンス-15秒までの待機時間-ウォームアップリクエストができるだけ速く（10秒未満）、それでもかなり長い間、frameWork Play（Java）を使用します。本当に問題が発生したくない場合は、アプリにpingを実行して偽のトラフィックを作成します。
この構成では、常駐者は通常約50のリクエストを処理します。その間、動的インスタンスはウォームアップを受信してから処理を開始します。