5

問題

サーバーから Firebase への最初の呼び出しには、後続の呼び出しよりも 15 ～ 20 倍の時間がかかります。これは、Firebase を呼び出す従来のサーバーでは問題になりませんが、Amazon Lambda/Google Cloud Functions を利用するサーバーレス アーキテクチャでは問題が発生する可能性があります。

質問

  • 最初の呼び出しが非常に遅いのはなぜですか? 認証によるものですか？
  • 回避策はありますか?
  • Amazon Lambda/Google Cloud Functions を使用して Firebase DB でユーザーが開始したデータの計算を実行し、結果を 1 ～ 2 秒以内にクライアントに返すことは実用的ですか?

環境

Firebase をデータのリポジトリとして使用するサーバーレス アーキテクチャを使用し、Amazon Lambda/ Cloud Functions を使用して Firebase をサーバー側の計算 (他のユーザーの検索など) で拡張することを計画しています。クライアントからの HTTP リクエストを介して関数をトリガーするつもりです。

私が抱えていた懸念の 1 つは、サーバーから Firebase への最初の呼び出しに時間がかかることでした。ラップトップでサーバー側のコードをテストしているときに、最初のリスナーが 6 秒で戻ってきました。後続の呼び出しは 300 ～ 400 ミリ秒で返されます。データセットは非常に小さく (2 ～ 3 個のキーと値のペア)、オブザーバーを交換してテストしました。

比較すると、ラップトップから Google Maps API を呼び出すと、返されるまでに約 400 ミリ秒かかります。

サーバーからの応答時間がかなり高速になることを認識しています。最初の呼び出しでまだ 15 倍から 20 倍という係数は当惑させられます。

4

2 に答える 2

1

ありがとうフランク!! firebase が Web ソケット接続を確立する方法を読んでください。

フランクの答えに加えて、最初のハンドシェイクは最初のプルで遅延を引き起こします。このアプローチにより、その後のデータ プルが大幅に高速化されます。米国西海岸のサーバーで実行されている Amazon Lambda インスタンスでテスト中。応答時間は次のとおりです。1)最初のプル: 1.6 ～ 2.3 秒2)後続のプル: 60 ～ 100 ミリ秒。データセット自体は非常に小さいため、これらの期間は単にサーバー間通信のためのものであると推測できます。ポイント:

  • Amazon Lambda インスタンスは、タイム クリティカルではない計算のために API ゲートウェイを介してトリガーできますが、検索結果を返すなど、Firebase データのリアルタイム計算には理想的なソリューションではありません (インスタンスに対するハンドシェイクの永続性を保証する方法がない限り)。私が読んだものから）
  • タイム クリティカルな計算のために、Firebase Queue を利用して EC2/GAE インスタンスを実行します。https://github.com/firebase/firebase-queue . このアプローチは、ラムダ インスタンスを起動するよりも複雑ですが、結果がより速く返されます (すべてのタスクのハンドシェイクが回避されるため)。
于 2016-10-21T19:56:52.687 に答える