爲什麼來自服務器的第一個Firebase調用需要比後續調用更長的時間才能返回？

Question

問題

首先要火力地堡從服務器調用需要15 - 20倍比後續調用更長。雖然這對調用Firebase的傳統服務器不是問題，但它可能會導致利用Amazon Lambda/Google Cloud Functions的無服務器體系結構的問題。

問題

• 爲什麼是第一次調用這麼多慢？是否由於身份驗證？
• 是否有任何解決方法？
• 使用Amazon Lambda/Google Cloud Functions在Firebase數據庫上執行一些用戶啓動的數據計算並在1-2秒內將結果返回給客戶端是否切實可行？

語境

我使用無服務器架構，火力地堡作爲我的數據和亞馬遜的λ/雲功能增強火力地堡一些服務器端的計算，例如的倉庫規劃搜索其他用戶。我打算通過來自我的客戶端的HTTP請求來觸發這些功能。

我擔心的一件事是從服務器第一次調用Firebase所花費的大量時間。在我的筆記本電腦上測試一些服務器端代碼時，第一個偵聽器會在6秒後返回！隨後的電話會在300 - 400毫秒內返回。數據集非常小（2 - 3個關鍵值對），我也通過交換觀察者進行測試。

相比之下，從我的筆記本電腦撥打Google Maps API大約需要400ms才能返回。

我意識到服務器的響應時間要快得多。第一次通話仍然是15 - 20X的一個因素，令人不安。

Answer 1

謝謝弗蘭克！閱讀firebase如何建立網絡套接字連接。

要添加到Frank的回答中，初始握手會導致第一次拉的延遲。該方法大大加快了後續的數據提取速度。在美西海岸服務器上運行的Amazon Lambda實例上進行測試。響應時間爲：1）第一次拉：1.6-2.3s 2）後續拉：60-100ms。數據集本身非常小，因此可以假定這些時間段僅用於服務器到服務器的通信。小貼士：

• 亞馬遜拉姆達實例可以通過非時間關鍵型計算的API網關被觸發，但不是在火力地堡數據實時計算，例如返回搜索結果（除非有辦法的理​​想解決方案保證持久握手實例 - 而不是我讀過的）
• 對於時間關鍵型計算，我將使用Firebase隊列運行EC2/GAE實例。 https://github.com/firebase/firebase-queue。該方法涉及比發射lambda實例更多，但會更快地返回結果（因爲避免了每個任務的握手）。

Answer 2

TL; DR：你注意到，上已知/預期的東西，但我們將剃下來的懲罰，GA方法。一些改進將會比以後更早。

Firebase團隊成員的雲端函數。我們能夠在持續缺乏負載之後，通過「擴展至零」（關閉所有實例），以具有競爭力的價格提供雲功能。當請求進入並且您沒有可用的實例時，Cloud Functions會根據需要爲您創建一個。這顯然比打一個活躍的服務器慢，而且我們稱之爲「冷啓動」。冷啓動是「無服務器」架構現實的一部分，但我們有許多人正在努力減少懲罰。

還有另一種情況是我最近開始稱「溫熱」開始。部署完成後，Cloud Function實例已創建，但您的應用程序仍需進行熱身工作來完成與Firebase實時數據庫的連接。正如你所建議的，這個的一部分是認證。我們發現這裏將出現放緩，下週將會修復。之後，您仍然需要爲SSL + Firebase握手付費。嘗試衡量這種延遲;目前尚不清楚我們能夠繞過它多少。