私は、GAE スケジューラーが精査され、注目されていることを知っています。また、アプリケーションのパフォーマンスにとって重要であることもわかっています。私は先週、アプリケーションの最適化と分析に費やしました。
また、スケジューラはアプリケーション サイズの範囲全体で動作するように設計されており、アルゴリズムは、同時ユーザーの観点から、比較的小規模なアプリケーションには最適化されていない可能性があることも理解しています。
保留中のレイテンシに関する次の説明は間違っていると思います。これにより、避けられない遅延が発生します。
Pending Latency スライダーは、アプリケーションのデフォルト バージョンのインスタンスによって処理される前に、リクエストが保留キューに留まる時間を制御します。保留中の最小レイテンシが高い場合、App Engine はリクエストを処理するために新しいインスタンスを開始するのではなく、待機することを許可します。これにより、アプリケーションが使用するインスタンス時間数を減らすことができますが、ユーザーに見えるレイテンシが増える可能性があります。
保留中のレイテンシが 15 秒で、アイドル状態のインスタンスが 2 つある場合、10 個のリクエストをシリアルで実行すると、すべて 1 ～ 3 秒かかります (マルチスレッドが有効になっている場合)。
なぜ私は気にするのですか？すべての初期化をウォームアップ コードに入れることができますか? 違う。JDOでGAE/Jを使用しています。数秒の「検証」オーバーヘッドが発生する最初の時間に、各インスタンスがエンティティタイプにヒットするようです。ほとんどの場合、JDO ロギングを INFO レベルに設定しない限り、これが発生していることさえわかりません。
私の質問は次のとおりです。
スケジューラーの動作と、DS の初期化との相互作用に関連して次のような状況を経験した人はいますか? もしそうなら、そのような遅延の発生を避けるための解決策を提案できますか?
具体的には、次のような状況です。
- JDO を使用 - 新しいインスタンスが初めてエンティティ タイプに「触れる」たびに、初期化のオーバーヘッドが発生します (疑わしい場合は、JDO のログ レベルを INFO に設定してください)。このオーバーヘッドは 2 ～ 3 秒程度です。
- このオーバーヘッドの結果としてレイテンシーが増加し、スケジューラーが Pending Latency パラメーターを明確に無視するという事実と相まって、既存のインスタンスがリクエストを処理できると計算するよりも、新しいインスタンスをスピンアップする可能性が高いことを意味します。
- 新しいリクエストは新しいインスタンスによって処理されるため、上記の初期化オーバーヘッドは繰り返されます。したがって、悪循環が永続します。
私はすでに次の救済策を検討していることに注意してください。
- 休止状態または同様のものへの移行 - 巨大な作業であり、問題が解決するかどうかは不明です。
- バックエンドを使用してすべての DB 機能を提供するようにアプリケーション アーキテクチャを変更します。少なくとも、実行している数を制御できるなどです。
- おそらく、上記のオーバーヘッドを単に回避するために欠落しているJDO構成がいくつかありますか？