"Hibernating"サービスファブリックアプリケーション

Question

私はサービスファブリックに変換して以来、私が構築している小さなサービスファブリックアプリケーションを持っています。これは、起動時間が遅いことに悩まされていました。リリースの後だけでなく、非活動の15分。

私は、各サービスに行き、10秒ごとに小さなdb要求を出し、アプリケーションとefを実行し続けることを考えているプロジェクトを追加しました。これは私がタイムアウトを得るのを助け、最初の要求は5-15秒の範囲にあります。ウォーミングアップ後、要求は通常300msの範囲にあるので、非常に簡単な要求であり、サービス間の通信はあまりありません（合計4つのサービス）。

多くの検索の後、私は、ほとんどがビジュアルスタジオのものが好きではないように見えるプロファイラを見つけました。残念なことに、スレッドをたくさん待っていて、それが自分のコードに含まれていないように見えることを除けば、それほど大したことはありませんでした。私の外部リクエストはすべて非同期で待機します。また、要求に従うと、情報が欠落しているように思えました。

最初は、検索クエリを生成してから遅くなるかもしれないので、その部分を代わりに使用してその部分を移行しました。いくつかのef）しかし、それは何も実際に変更されませんでした。

このアプリケーションには、最新のサービスファブリック、dotnetコア、efコア、アプリケーションの洞察力のあるパッケージがすべて含まれています。トークンを検証するものを除くすべてのサービスはステートレスです。もちろん、リリースモードで構築されています。

私はそんなに遅い理由を見つけることができないので、ちょっと迷っています。昔は、これは通常、IISがアプリケーションをシャットダウンしたり、リサイクルしていたためでしたが、今はそこにないときには何ができますか？

Answer 1

私たちはDIコンテナを使用しますが、我々のサービスへの最初の呼び出しまで、すべての依存関係は解決されず、これらのインスタンスを作成するのに時間がかかります。たとえば、クラスのシングルトン。もう1つはEF DBのコンテキストです。それを克服するために、我々はまずサービスを「暖かく」するプロセスを持っています。

Answer 2

を助け

ホープこれは、暗闇の中でショットのかもしれません：あなたのサービスでは、サービスファブリックリモーティングオプションを使用して通信を行うか、HTTPを使用していますか？ HTTPの場合、Hibernationとウォームアップ時間はHttpSys/Kestrelによって引き起こされる可能性がありますか？

少し奇妙に思える低速応答（300ms）に関しては、私たちはバックエンドのEFと複数のステートレスサービス（HTTPとKestrelを使用し、応答時間50ms以下）を持っています。