私たちには、DocumentDBクエリを行う簡単なAzure関数があります。私たちが最初にそれを呼び出すように長い待ち時間があり、その後の呼び出しが非常に速いようです。Azure関数が "起床"するのに時間がかかりすぎるのはなぜですか？
たとえば、私はアプリを開いたばかりで、最初の関数呼び出しには10760msかかりました。これはエンドユーザーにとってはっきりと目立つものです。この後、すべての関数呼び出しは処理に約100msかかり、ほとんど知覚できません。
Azure関数では、「起床」のサイクルがあるようです。これを最小限に抑えるための方法はありますか、それともどこかに記載されているので、ここで実際に何が起こっているのか理解できますか？
機能消費計画で実行されている機能アプリは、実際には有効時間を過ぎてから効果的にスリープ状態になります。次の呼び出しは、あなたが観察したように "目を覚ます"ために必要で、人々はコメントで言及しています。
なぜこのようなことが起きるのかについては、マイクロソフトがマルチテナント環境でコンピューティングワークロードを最も最適に配布できるようにするとともに、実際に仕事をしている時間帯にのみ2番目に請求するようにします。これはサーバーレスの美しさです。
これは許容されない動作の場合、消費計画から実際のAppサービス計画に移行することを検討できます。あるいは、毎分毎分オフになるタイマートリガー機能を実装し、スリープ状態に移行したくない機能にpingを実行することで、「keep alive」メカニズムとして使用することもできます。
同じ機能アプリで4分タイマーを使用して機能を追加しましたが、アイドル状態から来るように見える場合がある10〜20秒の実行時間がまだまだ続きます。ここで遊ぶのは何か他のものでしょうか？ – Graham
Appサービスプランに移行し、常時接続機能を活用しましょう：https://github.com/Azure/Azure-Functions/wiki/Enable-常に - オン - いつか - ランニング - オン - ダイプリド - アプリケーション - サービス - プラン – evilSnobu
これについてもう少し考えた後、Appサービスプランに移行しようとすると、ネイティブのnode.jsコードを作成して、関数オーバーヘッドに煩わされることはありません。 – Graham
あなたは私の理解に基づいて、アイドル時間の5分後に、あなたの機能がコールドスタートモードに入ることを意味します。コールドスタートモードへの変更を防ぐことは非常に簡単です。 5分ごとに実行される同じ関数app内に時間トリガ関数を追加するだけです。ただし、無料の実行クレジットが超過すると、追加費用が発生する可能性があることに注意してください。 – Hackerman
これはまだCosmosDB DocumentDB（hehehe）ですが、バックエンドサービスであった可能性があります。このコールドスタートはまだ見えます。これはどこに文書化されていますか？ – Graham
私はそれをここで見つけたhttps://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app/ ...その言葉：コールドアイドル状態になった後、機能アプリへの最初のリクエストで開始されます。これは、5分間の非アクティブ後に発生します。関数Appが起動すると、すべての関数のインデックスが作成され、C＃およびF＃スクリプトがメモリ内のアセンブリにコンパイルされます。したがって、コールドスタート時間にコンパイル時間が追加されます。機能実行が開始されていないため、顧客はコールドスタートの料金が請求されませんが、イベント処理の遅延が発生します。 – Hackerman