Firebase-tools: Bereitstellung von Funktionen extrem langsam

Danke für die Einreichung! Wir wissen, dass die langsame Bereitstellung ein großer Schmerzpunkt für die Funktionserfahrung ist, und wir arbeiten daran, dies durch verschiedene Strategien zu lösen.

@laurinlong
Als Firebase-Neuling dachte ich auf den ersten Blick, ich hätte etwas vermasselt, weil das Deployment immer beim Teil _functions: Funktionsverzeichnis zum Hochladen vorbereiten..._ aufhörte.
Es wäre wirklich nett, einige zusätzliche Informationen zu geben (z. B.: Es dauert 3-5 Minuten, bis das Problem gelöst ist).

Als Neuling habe ich viele Male damit verbracht, diesen Gedanken zu stornieren, dass ich etwas falsch mache.

Das Problem ist irgendwie offensichtlich. Der init-Befehl hat einen riesigen Ordner „Knotenmodule“ erstellt. Auf meinem Rechner sind es: 22.903 Dateien, 2.782 Ordner. Der Code kopiert all das in einen temporären Ordner.

Folgendes habe ich getan:

1. Mithilfe von Protokolldruckanweisungen habe ich die langsame Codezeile identifiziert. Es ist hier:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

Zeile 26 in PrepareFunctionsUpload.js:
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. Ich habe die Parameter für diesen Dateikopieraufruf ausgedruckt. Auf meiner Maschine ist es:
   C:\Users\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Users\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

Der Funktionsordner wurde mit dem CLI-Befehl init erstellt. Es sieht aus wie das:

• node_modules (enorme Größe)
• .gitignorieren
• index.js
• Paket.json
• Paket-lock.json

Es scheint mir, dass der CLI-Befehl init diesen node_modules-Ordner NICHT hätte erstellen sollen. Es ist 165 MB groß. Das erscheint unvernünftig, um es jedem Projekt hinzuzufügen.

@thomasfischer

Das ist eigentlich nicht das Thema. Die node_modules werden nicht in den temporären Ordner kopiert, wie Sie in dieser Zeile hier sehen können: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

Es ist für firebase init erforderlich, alle Knotenmodule lokal im Quellordner der Funktionen zu installieren, andernfalls funktioniert die lokale Bereitstellung der Funktionen nicht und die Trigger-Extraktion funktioniert nicht (auf diese Weise versteht die CLI, welche Ereignisse jeweils ausgelöst werden funktionieren, damit es sie richtig bereitstellen kann).

Ich habe eine Debug-Druckzeile vor Zeile 26 und danach eingefügt. Diese Linie dauerte Minuten.

Dann fügte ich einen Filter hinzu, um auszudrucken, welche Dateien kopiert wurden. Es enthielt alle node_modules-Dateien.

Dann habe ich den Filter geändert, um die node_module-Dateien auszuschließen. Der Einsatz ging jetzt schnell voran. Wenig später schien es jedoch, dass das Skript versuchte, die Korrektheit der Cloud-Funktionen zu bewerten. Dieser Code ist fehlgeschlagen, weil ihm die Bibliotheksabhängigkeiten fehlten.

Die Quellcodezeile, auf die Sie zeigen, scheint ein späterer Schritt zu sein. Es scheint, als würden die Dateien (abzüglich der node_modules) vor dem Hochladen in die Cloud in einer ZIP-Datei archiviert. Diese Zeile scheint auf meinem Rechner nicht langsam zu laufen.

Ja, Sie haben Recht, ich habe mich geirrt, node_modules wird kopiert. Ich denke, es ist eine gute Idee, node_modules nicht in das Temp-Verzeichnis zu kopieren. Was dies etwas komplizierter macht, ist die Tatsache, dass die CLI vor dem Trigger-Parsing eine „.runtimeconfig.json“ in den temporären Ordner schreibt und diese Datei mit dem Rest des Funktionsquellcodes hochgeladen wird, und wir wollten nicht schreiben diese Datei in das eigentliche Quellcodeverzeichnis. Es gibt also wahrscheinlich eine gute Lösung, die sowohl die Bereitstellungsgeschwindigkeit verbessert als auch sicherstellt, dass es keine unbeabsichtigten Nebenwirkungen gibt, aber ich müsste ein bisschen damit herumspielen. Sie können auch gerne eine Pull-Anfrage stellen.

Ich habe das gleiche Problem. Es könnte eine gute Idee sein, während der Schritte „Vorbereitung des Verzeichnisses…“ weitere Meldungen zu drucken, damit der Benutzer nicht denkt, dass firebase-tools hängt.

Bearbeiten: Dies war auf Ubuntu WSL. Unter Linux hängt die "Vorbereitungsphase" nicht. Der Schritt "Funktion erstellen" kann langsam sein, aber nicht so viel, wie ich es früher erlebt habe.

Dieses Problem ist ein echter Schmerz im Hintern. Ich denke, es sollte hohe Priorität haben :/

Ich versuche, Firebase-Funktionen in mein Projekt zu implementieren, und aufgrund dieses Fehlers musste ich es verschieben.
Dieser Fehler hat mich viel Zeit verschwenden lassen.
hoffe es wird bald behoben!

Dieses Problem ist ein großes Hindernis. Hauptsächlich, weil ich Firestore verwende und in solchen Dingen wie Aggregaten, Zählern und Präsenz nur anständig von Cloud-Funktionen gehandhabt werden kann und es jedes Mal nur für 5 Minuten hängt.

@PulpoEnPatineta Dies ist kein Fehler. Dies ist einfach ein Problem mit der Bereitstellungszeit.

@McStuffins Wenn Ihr Auto fünf Minuten zum Einschalten braucht, ist das ein Fehler oder einfach ein Problem mit der Startzeit?

gibt es dafür eine Lösung? Es ist wirklich extrem langsam.

Ich habe dieses Problem von Anfang an verfolgt, aber es war nie ein Problem für mich, da ich eine CD eingerichtet habe und es die ganze Arbeit für mich erledigt. Ich setze auch nie Funktionen ein, nur um zu testen, ob sie funktionieren. Also im Grunde war es mir egal.

Bis heute, als ich auf eine unerwartete Einschränkung gestoßen bin: Ich kann meine Funktionen nicht mehr bereitstellen, da die Bereitstellung in der Produktion das Tageskontingent (12.000 Sekunden) überschreitet. Ich habe ~55 Funktionen mit verschiedenen Triggern (Pubsub, Firestore, https). Ist es zu viel zu handhaben?

Jetzt muss ich meine Anwendung zwei Tage lang bereitstellen :rofl: :lollipop: :+1: :1st_place_medal: :coffin: :tada: :taco: :cactus: :dancer: :smiling_imp:

Manchmal ist es beim Deployment extrem langsam, und dann gibt es im Terminal eine Warnung mit der Aufschrift „Fehler in der Build-Umgebung“.

@srinurp Bitte sehen Sie sich den Pull-Request an, den ich oben verlinkt habe, er wird einen Teil des Problems lösen. Und das Back-End-Team arbeitet daran, andere Teile des Problems zu lösen (aber es ist ein sehr kompliziertes Unterfangen, daher wissen wir Ihre Geduld zu schätzen).

@merlinnot Wenn Sie nicht bei jeder Bereitstellung den Code für alle Ihre Funktionen aktualisieren, würde ich empfehlen, den Befehl --only zu verwenden, um einzelne Funktionen oder Gruppen von Funktionen bereitzustellen. Siehe https://firebase.google.com/docs/cli/#partial_deploys.

@McStuffins „Fehler in der Build-Umgebung“ weist normalerweise auf ein Produktionsproblem hin. Reichen Sie in diesem Fall bitte ein Support-Ticket unter https://firebase.google.com/support/ ein. Sie können sehen, ob es laufende Produktionsprobleme gibt, indem Sie die besuchen Firebase-Status-Dashboard

@laurenzlong Ich müsste mein CI so konfigurieren, dass Änderungen in jeder Funktion zwischen Bereitstellungen automatisch erkannt werden (einschließlich der Auflösung von Abhängigkeiten). Und was ist, wenn ich Pakete wie firebase-functions , firebase-admin , lodash usw. aktualisiere, die ich in jeder einzelnen Funktion verwende?

@merlinnot Das ist ein sehr legitimer Anwendungsfall. Bereitstellungskontingente werden von den Google Cloud-Funktionen gesteuert. Ich würde empfehlen, eine Anfrage an deren Public Issues Tracker zu stellen: https://cloud.google.com/functions/docs/support

Für alle Interessierten: https://issuetracker.google.com/issues/71385193

@laurenzlong Könnte der Ordner node_modules beim Kopieren der Quelle ignoriert werden und dann ein npm install --production oder yarn install --production ausführen? Da diese Tools möglicherweise schneller sind als einfaches Kopieren und Einfügen.

@horacehylee
Dies könnte eine bahnbrechende Änderung sein. Einige Leute (mich eingeschlossen) referenzieren Pakete möglicherweise immer noch über einen relativen Pfad (wie "Paketname": "./externs/package.tgz"), hauptsächlich wegen des ( jetzt behobenen) Problems mit privaten Repositories. Das Tool müsste alle diese Eckfälle berücksichtigen.

Die andere Sache ist das Caching: Wenn Google Pakete in Ihrem Namen herunterladen würde, müssten sie einen internen Caching-Mechanismus implementieren. Wir alle haben lokale Caches auf unseren Computern (sowohl npm als auch Garn haben Caching-Mechanismen), daher beenden wir die Server von npm nicht;)

Einige Leute möchten vielleicht auch einfach einige Änderungen in externen Bibliotheken testen. Es ist viel einfacher, einfach eine Datei zu ändern und die Funktion bereitzustellen, als einen Fork zu erstellen, Änderungen vorzunehmen, einen Verweis auf das Paket vorübergehend zu ändern, ...

Fazit: es funktioniert prima, lass es so wie es jetzt ist :+1:

@horacehylee @merlinnot Danke für die 2 Cent. Bitte beachten Sie https://github.com/firebase/firebase-tools/pull/578 , die nächste Version der CLI wird den Zeitraum des Funktionsquellordners nicht mehr kopieren.

Ich bin mir wirklich nicht sicher, was Firebase tun könnte, das MINUTEN benötigt, um eine 5-Zeilen-, 1-kb-Funktion auf einer Maschine mit sechs 4-GHz-Kernen bereitzustellen, die auf einer 1-Gbit / s-Glasfaserverbindung sitzt.

Ich weiß, es klingt, als würde ich mich verarschen, aber ich bin wirklich neugierig, was während "Verzeichnis zum Hochladen vorbereiten" vor sich geht. Kennt sich eigentlich jemand aus?

Kopieren Sie Ihr Funktionsverzeichnis, einschließlich Knotenmodule, in ein tmp-Verzeichnis.

Unsere nächste Version wird dies beheben und muss nicht mehr vorher kopiert werden
bereitstellen.

Am Sonntag, 7. Januar 2018, 17:05 Uhr schrieb hmexx [email protected] :

Ich bin mir wirklich nicht sicher, was Firebase tun könnte, was Minuten dauert
Stellen Sie eine 5-Zeilen-, 1-kb-Funktion auf einer Maschine mit sechs 4-GHz-Kernen bereit, die auf einem sitzt
1 Gbit/s Glasfaserverbindung.

Ich weiß, es klingt, als würde ich mich verpissen, aber ich bin wirklich neugierig, was
läuft während "Verzeichnis zum Hochladen vorbereiten". Kennt sich eigentlich jemand aus?

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

Ah richtig. das erklärt es. Es ist irgendwie komödiantisch zu sehen, wie eine Workstation für ein oder zwei Minuten verrückt spielt, nur um die nächste Zeile "gepackte Funktionen ( 37,55 kb !!!) erfolgreich zum Hochladen" ausgeben zu sehen, lol

Freuen Sie sich auf die nächste Veröffentlichung. Thx für die Antwort.

H.

Tag 19. Firebase wird immer noch bereitgestellt. *schnappt sich Popcorn*

Ja.

Wann ist die nächste Version geplant und wie viel % Verbesserung der Bereitstellungszeiten können wir erwarten?

Nur um zu wissen, ob man diesen Weg weitergehen soll.

Die Veröffentlichung sollte diese Woche erfolgen, und Sie können die „Preparing
Functions-Verzeichnis für das Deployment", um wesentlich schneller voranzukommen (ich tue es nicht
haben genaue Zahlen). Andere Teile der Bereitstellung bleiben unverändert.

Am Mo, 15. Januar 2018 um 12:42 Uhr schrieb hmexx [email protected] :

Ja.

Wann ist die nächste Version geplant und wie viel Prozent Verbesserung bei der Bereitstellung
Zeiten sollten wir erwarten?

Nur um zu wissen, ob man diesen Weg weitergehen soll.

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

Das wurde freigegeben!

@mbleigh Ist das in Version 3.17.4?

@jkosis v3.17.0

Aus den Versionshinweisen:

Wenn Sie Funktionen bereitstellen, müssen Sie das Firebase-Funktions-SDK auf die neueste Version aktualisieren, indem Sie „npm i --save firebase -functions@latest “ in Ihrem Funktionsverzeichnis ausführen. Dies ermöglicht eine schnellere Bereitstellung von Funktionen.

von minuten zu sekunden: gute arbeit!

Bei mir dauert das noch Minuten.

Ich habe [email protected] und [email protected] . Was kann ich tun, um dieses Problem weiter zu beheben?

Hier ist die zeitgesteuerte Ausgabe, wenn nur Funktionen bereitgestellt werden. Ich habe die Namen geändert, aber sie sind eine Kombination aus REST-Endpunkten, Datenbank- und Authentifizierungstriggern.

➜  functions git:(master) ✗ firebase --version
3.17.4
➜  functions git:(master) ✗ time firebase deploy --only functions

=== Deploying to 'XXX'...

i  deploying functions
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (123.07 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: updating function 1...
i  functions: updating function 2...
i  functions: updating function 3...
i  functions: updating function 4...
i  functions: updating function 5...
i  functions: updating function 6...
✔  functions[1]: Successful update operation.
Function URL (1): https://us-central1-XXX.cloudfunctions.net/1
✔  functions[3]: Successful update operation.
✔  functions[4]: Successful update operation.
✔  functions[5]: Successful update operation.
✔  functions[6]: Successful update operation.
✔  functions[2]: Successful update operation.
Function URL (2): https://us-central1-XXX.cloudfunctions.net/2

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/XXX/overview
firebase deploy --only functions  4.59s user 1.07s system 1% cpu 6:09.26 total

@adamduren der Fix war für eine übermäßige Zeit, die in preparing functions directory for uploading... verbracht wurde

Die Bereitstellungen selbst können noch ziemlich lange dauern.

Stack in der gleichen Situation:

"firebase-admin": "^5.8.2",
"firebase-functions": "^0.8.1",

npm install -g npm@latest gab mir etwas andere Eingaben, und das Entfernen firebase-cli schien auch etwas zu ändern.

aktualisieren:

okay, nachdem ich npm install -g firebase-tools ausgeführt hatte, funktionierte es endlich. Kudos an https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993

Hallo, ich habe an der gleichen Stelle ein Problem ("Vorbereitung des Funktionsverzeichnisses ...")
aber in meinem Fall hat es mehr als 25/30 Minuten gedauert
Ich habe 4 private Abhängigkeiten, die komprimiert etwa 2,20 MB wiegen
Ich fand, dass dies die einzige Möglichkeit war, private Abhängigkeiten als komprimierte Dateien einzuschließen.
mache ich etwas falsch? oder soll das so funktionieren?

2018-5-9
firebase deploy immer noch langsam, nicht sicher warum

Hast du auf die letzte Version aktualisiert? Ich habe letzte Woche aktualisiert und jetzt dauert meine Bereitstellung 1-3 Minuten (vom 25./30.)

Ich sehe Bereitstellungszeiten von mehr als 4 Minuten für etwas so Einfaches wie:

const functions = require('firebase-functions')

exports.test = functions.https.onRequest((req, res) => {
  res.send('Hello World')
})

i functions: updating function test... ist die Linie, die hängt.
So langsam war es noch nie!

@Robula Hast du auf die neueste Version von Firebase-Tools aktualisiert?

Ja, ich glaube schon. firebase —version Berichte 3.18.6.

Du hast eine neuere Version als ich. Ich bin mir nicht sicher, ob sie den Ordner node_modules vielleicht in 3.18.6 erneut übertragen haben, aber im Moment scheint mit 3.18.4 alles gut zu laufen ...

In den letzten Firebase-Tools-Versionen gab es keine Regression in der Bereitstellungsstrategie (der Ordner „node_modules“ wird nicht kopiert), die Bereitstellungszeit variiert jedoch auch von Maschine zu Maschine und von Zeit zu Zeit. Die anfängliche Bereitstellung einer Funktion ist auch langsamer als nachfolgende Aktualisierungen.

Ich sehe, dass die Bereitstellungszeiten während des Schritts preparing functions directory for uploading... allein für diesen Schritt fast 7 Minuten dauern, wenn er lokal ausgeführt wird. Der Pre-Deployment-Schritt für den Build dauert lokal etwa 5 Sekunden. Alle anderen Schritte im Bereitstellungsprozess werden vom Debug-Prozess sehr schnell ausgeführt. Ich verstehe, dass die Bereitstellung etwas langsam sein kann, aber ich verwende auch AWS Lambda für die Arbeit, und sehr große Lambda-Bereitstellungen sind viel viel schneller als diese, in der Größenordnung von 2 zwei 3 Minuten, einschließlich Installationen und Builds von Python-Paketen.

Selbst die Bereitstellung von Google Cloud Build dauert 2 bis 3 Minuten, im Vergleich zu 10 bis 20 Sekunden in aws Lambda. Ich möchte nur fragen, ob das CLI den gesamten Funktionsordner vor dem Hochladen komprimiert?

@laurenzlong , könnten Sie erläutern, ob die Funktionen bereits parallel bereitgestellt werden oder ob diese Optimierung in Arbeit ist?

Funktionen wurden immer parallel bereitgestellt. Beachten Sie jedoch, dass die parallele Bereitstellung von 10 Funktionen immer noch langsamer ist als die Bereitstellung einer einzelnen Funktion.

+1 Dass das Bereitstellen einer Funktion extrem langsam ist. Ich habe das Cron-Job-Tutorial befolgt, um die stündliche Tick-Funktion zu erstellen, meinen allerersten Ton, und es dauert jedes Mal etwa eine Minute, um sie bereitzustellen.

@laurenzlong vielen Dank für Ihre Antwort und vielen Dank für Ihre harte Arbeit an Firebase!

Gibt es aktive Pläne zur Verbesserung der Bereitstellungszeit? Ich frage, weil wir Firebase zwar mögen, aber aufgrund der langsamen Bereitstellungszeiten tatsächlich darüber nachdenken, uns davon zu entfernen. Wir haben ungefähr 47 Cloud-Funktionen und es dauert regelmäßig 3-6 Minuten für unsere Bereitstellungen. Vergleichen Sie das mit git push heroku master , was etwa 20-30 Sekunden dauern würde, um die gleiche Codemenge in Heroku bereitzustellen. Und dieser Code würde dann sofort auf Heroku ausgeführt. Bei Firebase müssen wir nach der Bereitstellung weitere 20–30 Sekunden (zufällig) warten, bevor die bereitgestellten Funktionen tatsächlich ausgeführt werden (während dieser Zeit wird eine Mischung aus neuen und alten Funktionen ausgeführt).

Vergleichen Sie also die Bereitstellungserfahrung:

*** Heroku:

git push heroku master

20-30s later ...

All newly-deployed functions are now running in a consistent/atomic way

*** Firebase:

firebase deploy --only functions

180-360s later ...

Functions are deployed but only some of the new ones are running, some old ones are still running

20-30s later ... 

All new functions running

Es ist auch schwierig, atomare Bereitstellungen mit Firebase durchzuführen, da es nach der Bereitstellung einen Zeitraum gibt, in dem einige der neuen Funktionen, nennen Sie sie v_n+1 , neben einigen der alten Funktionen v_n ausgeführt werden. Wenn Sie also ein größeres Update durchführen, haben Sie eine Mischung aus neuen und alten Funktionen, die möglicherweise mit unterschiedlichen Datenformaten oder Algorithmen ausgeführt werden. Dies ist viel weniger sicher als eine Heroku-Bereitstellung, bei der entweder alle neuen Funktionen bereitgestellt werden und nur neue Funktionen ausgeführt werden oder gar keine bereitgestellt werden.

Außerdem werden einige unserer 47 Funktionen manchmal mit Fehlern wie

⚠  functions[retrieveFavorites(us-central1)]: Deployment error.
Server Error. getaddrinfo ENOTFOUND cloudfunctions.googleapis.com cloudfunctions.googleapis.com:443

Wir verwenden hochzuverlässiges symmetrisches Gigabit-Internet, das Problem ist also nicht unser Netzwerk.

Stellen Sie sich Heroku-Bereitstellungen also als eine Art atomare DB-Transaktion (alles oder nichts) vor, während Firebase-Bereitstellungen eher mit teilweisen Fehlern übereinstimmen ... Dies erschwert die Entwicklung erheblich, insbesondere wenn Sie eine Fehlerbehebung durchführen mitten in der Nacht als Antwort auf einen Page.

Um ehrlich zu sein, das Deployment-Erlebnis auf Firebase ist objektiv langsamer und weniger zuverlässig als auf Heroku oder AWS ... Verstehen Sie mich nicht falsch, wir mögen Firebase und wissen all Ihre harte Arbeit wirklich zu schätzen. Ich meine nicht, dass das wie ein Angriff klingt, es ist nichts Persönliches, aber wir brauchen Firebase, um hier besser zu werden, oder wir denken darüber nach, woanders hinzugehen, weil Bereitstellungen einfach zu schmerzhaft sind.

Nochmals vielen Dank für Ihre harte Arbeit an Firebase. Wir schätzen Ihre Hilfe :-).

Danke, dass Sie Ihren Datenpunkt geteilt haben! Wir haben einige Pläne, dies zu verbessern, insbesondere um viele Funktionen gleichzeitig bereitzustellen (hauptsächlich Verbesserung des serverseitigen Build-Schritts nach dem API-Aufruf zum Erstellen/Aktualisieren der Funktion). Dies sind jedoch Infrastrukturänderungen, die Quartale dauern werden, daher wissen wir Ihre Geduld in der Zwischenzeit sehr zu schätzen.

Möglicherweise haben Sie dies bereits in Betracht gezogen, aber Sie können ein Skript in Ihrer CI/CD-Pipeline erstellen, das erkennt, welche Funktionen bearbeitet wurden, und nur diese mit dem --only -Flag bereitstellen. Dadurch wird Ihre Bereitstellungsgeschwindigkeit erheblich verbessert. Sehen Sie sich dieses Video als Beispiel an: https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong Danke für die Info, Lauren. Ich habe jedoch nur eine kleine Cloud-Funktion und die Bereitstellung dauert immer noch etwa 1 Minute, selbst nachdem ich die kleinste Änderung vorgenommen habe. Ich verwende dieses Flag auch, obwohl ich nur eine Cloud-Funktion habe. Hier scheint etwas schief zu laufen.

Ab April 2019 – Firebase-Version 6.6.0 – dauert es immer noch buchstäblich Minuten. Alles, was ich tue, ist, dem Tutorial hier zu folgen: https://firebase.google.com/docs/functions/get-started

Einfach heruntergeladen und es dauert jedes Mal ein paar Minuten, wenn ich "Firebase bereitstellen"

In den letzten paar Tagen dauerte die Bereitstellung sogar des Hostings mehrere Minuten, während es vor ein paar Wochen etwa 10-15 Sekunden dauerte. Auch das Bereitstellen von Funktionen läuft ab.

Und die Firebase-Statusseite ist grün https://status.firebase.google.com/ .

Weiß jemand warum das passiert?

Mit firebase-tools 7.0.0

$ firebase deploy --only=hosting --token xxx

=== Deploying to 'xxx'...

i  deploying hosting
i  hosting[xxx]: beginning deploy...
i  hosting[xxx]: found 1959 files in public
✔  hosting[xxx]: file upload complete
i  hosting[xxx]: finalizing version...
✔  hosting[xxx]: version finalized
i  hosting[xxx]: releasing new version...
✔  hosting[xxx]: release complete
✔  hosting: Finished running postdeploy script.

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/xxx/overview
Hosting URL: https://xxx.firebaseapp.com
✨  Done in 181.75s

@laurenzlong-

Dies sind jedoch Infrastrukturänderungen, die Quartale dauern werden, daher wissen wir Ihre Geduld in der Zwischenzeit sehr zu schätzen.

Irgendwelche infrastrukturseitigen Updates seit Ihrer letzten Notiz vor ein paar Quartalen? Ist es möglich, dieses Problem erneut zu öffnen, bis diese Änderungen vorgenommen wurden? Geschlossen scheint nicht der richtige Status zu sein, es sei denn, die Verfolgung wurde zu einem anderen/verwandten Problem verschoben.

Firebase functions ist immer noch super langsam, nachdem alles erstellt/hochgeladen wurde und die Funktionen serverseitig erstellt/aktualisiert werden. Wie andere gesagt haben, ist dies ein wichtiger Dämpfer für die Entwicklungsgeschwindigkeit.

firebase --version
7.1.0

Vielen Dank für die Berücksichtigung!

@repentsinner , das Backend-Projekt zur Verbesserung der Build-/Bereitstellungszeiten ist noch im Gange (und läuft gut!), aber es ist immer noch nicht veröffentlicht.

Haben Sie versucht, den Emulator (über firebase emulators:start ) zu verwenden, um Ihren Entwicklungsprozess zu beschleunigen? Dann freuen wir uns über Ihr Feedback!

Danke für das Update @samtstern.

Ich habe den Emulator noch nicht ausprobiert - ich verwende functions.https.onCall aus einer Flatter-App sowie Daten in einem Firestore, und es scheint (im Moment jedenfalls) alles in den Test-Builds der App umzuleiten zu meiner Entwicklungs-Workstation ist mehr Aufwand als das Warten auf Deployments.

Ich denke, ich kann die Wartezeit nutzen, um mir das anzusehen 🤨.

Frohes neues Jahr für dieses Problem, das immer noch geschlossen und immer noch nicht behoben ist! 🎉

Vielleicht kann ein Administrator oder OP dieses Problem in „Vorbereitung des Funktionsverzeichnisses für die Bereitstellung extrem langsam“ umbenennen, da es scheinbar nur aufgrund einer Korrektur für diese Phase des gesamten Bereitstellungsprozesses geschlossen wurde.

Wir können dann ein neues Problem "Bereitstellen von Funktionen extrem langsam" eröffnen, da ... das Bereitstellen von Funktionen immer noch extrem langsam ist 😄

Dieses Problem wurde geschlossen, da wir auf der CLI-Seite nichts mehr tun können, um die Bereitstellungszeiten zu verbessern. Für die lokale Entwicklung investieren wir weiterhin in den Emulator. Wir hoffen, dass die Leute firebase deploy nur ausführen müssen, wenn sie für die Produktion bereitgestellt werden, und nicht als Teil ihres Entwicklungslebenszyklus.

Backend-Änderungen sind noch in Arbeit. Wie Sie sehen können, gab es unerwartete Verzögerungen.

Danke für die Klarstellung @samtstern , also denke ich, dass Probleme/Anfragen gegen Firebase/Firebase-Tools nur für die CLI gelten? Wird nach einem Repo/Projekt suchen, das das Backend abdeckt.

In Bezug auf die lokale Entwicklung – von der öffentlichen Seite der Dinge scheint es, als würde Google die Integration von Firebase und Flutter wirklich fördern, die auf den ersten Blick sehr gut zusammenzuarbeiten scheinen, aber in der Praxis stoßen wir auf solche Inkonsistenzen während der Entwicklungszeit. Ich habe einen kurzen Blick auf den Emulator geworfen, wie vorgeschlagen, als ich dieses Problem entdeckte, aber er schien einen integrierten Firebase plus Flutter-Entwicklungsworkflow überhaupt nicht zu unterstützen, sicherlich nicht so reibungslos wie über das Cloud-Backend. Ich habe nicht zurückgekreist, um zu sehen, ob sich dies in letzter Zeit verbessert hat, aber es scheint unwahrscheinlich.

@repentsinner ja, dieses Repo verfolgt nur die CLI-Arbeit. Natürlich versuchen wir, alles zu beantworten, was hereinkommt, aber oft müssen wir Probleme schließen, wenn wir hier nichts Produktives tun können. Unsere Backends sind nicht Open Source, weshalb wir im Allgemeinen auf den Firebase-Support verweisen, um Fehlerberichte oder Funktionsanfragen zu allgemeinen Firebase-Dingen einzureichen.

Was Flutter betrifft, so lieben wir es (siehe: https://github.com/FirebaseExtended/flutterfire), aber es ist wichtig zu beachten, dass es sich nicht um eine offizielle Firebase-Plattform handelt, was bedeutet, dass wir für solche Probleme nicht unsere volle Unterstützung anbieten können natives Android/iOS/Web. Vielleicht wird sich das eines Tages ändern, aber im Moment ist das die Situation.

Wenn Sie Fragen dazu haben, wie Sie Ihre Flutter-App mit den Firebase-Emulatoren verbinden, öffnen Sie ein Problem im FlutterFire-Repo und cc an mich, dann kann ich auch die richtigen Flutter-Leute einbeziehen.

Verstanden, danke für die Klarstellung @samtstern! Ich bin im Moment zu anderen Projekten übergegangen, werde aber im FlutterFire-Repo nachsehen, wenn ich mich wieder mit diesen Dingen befasse.

Der Emulator unterstützt keinen Authentifizierungskontext, daher ist er meiner Meinung nach zu 100% völlig nutzlos.

Am Ende habe ich festgestellt, dass meine Bereitstellungen eingefroren sind, weil ich versucht habe, dotenv zu verwenden

Ich stecke nur meinen Kopf hinein, um die Leute daran zu erinnern, dass dies immer noch ein Schmerzpunkt ist ✌️

Für Leute, die immer noch darauf stoßen – eine Sache, die ich als hilfreich empfand, war die Verwendung functions.ignore , um das Hochladen unnötiger Aufblähungen zu vermeiden. Ich denke, ein besonders gutes Beispiel ist .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

Ich habe Funktionen komplett fallen gelassen, da der Entwicklungsworkflow mehr als schmerzhaft ist.

Für Leute, die immer noch darauf stoßen – eine Sache, die ich als hilfreich empfand, war die Verwendung functions.ignore , um das Hochladen unnötiger Aufblähungen zu vermeiden. Ich denke, ein besonders gutes Beispiel ist .git :

"functions": {
    "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"]
  }

Dies führte tatsächlich zu einigen Ergebnissen. Läuft jetzt in etwa 65-70% der Zeit. Danke!

Interessant - standardmäßig befindet sich das Unterverzeichnis functions unterhalb des Projektstammverzeichnisses, sodass es keinen .git -Ordner gibt. Leute, denen das geholfen hat - wie sieht Ihre Verzeichnisstruktur aus?

@mbleigh Stimmt. Meine beste Vermutung ist, dass es schlau ist und diese auf das Funktionsverzeichnis anwendet.

@mbleigh Ich habe ein Nur-Funktionen-Repository, daher schien es ein wenig albern, ein Funktionsverzeichnis zu haben. Alles verlagerte sich nach unten in die Wurzel.

Das ist ein Auszug aus meinem firebase.json :

  "functions": {
    "ignore": [
      "__mocks__",
      ".cache",
      ".commitlintrc.yaml",
      ".dependabot",
      ".editorconfig",
      ".eslintrc.yaml",
      ".firebase",
      ".firebaserc",
      ".git",
      ".gitattributes",
      ".github",
      ".gitignore",
      ".lintstagedrc.js",
      ".nvmrc",
      ".prettierignore",
      ".prettierrc.yaml",
      ".vscode",
      "CHANGELOG.md",
      "cloudbuild.yaml",
      "codecov.yml",
      "CONTRIBUTING.md",
      "coverage",
      "cSpell.json",
      "decisions",
      "firebase.json",
      "firestore.indexes.json",
      "jest.config.js",
      "node_modules",
      "README.md",
      "rfcs",
      "scripts",
      "src",
      "test",
      "tsconfig.json",
      "tsconfig.production.json"
    ],
    "source": "."
  },

Ich würde es gerne ersetzen durch:
```
{
"include": ["lib", "package.json", "package-lock.json"]
}

FWIW Ich glaube, diese akzeptieren Globs, damit Sie möglicherweise Folgendes tun können:

{
  "exclude": ["!{lib,package.json,package-lock.json}"]
}

Cloud-Funktionen wurden gerade gestartet, und die Bereitstellungszeit ist schmerzhaft.

schmerzhafte Bereitstellungszeit :(

In unserer Firebase-App laufen jetzt 60 Cloud-Funktionen. Zuerst hatten wir viele Bereitstellungsfehler aufgrund von Kontingenten, also haben wir es dann in Stapel aufgeteilt, wie es die Dokumentation vorschlägt. Es wird jetzt konsistent bereitgestellt, aber die Bereitstellung jedes Stapels als Teil von GitHub-Aktionen CI auf den Standard-Runnern dauert ca. 3 Minuten. Die Batches sind jeweils etwa 6, also insgesamt 10 Batches, wodurch unsere Funktionsbereitstellungszeit etwa 30 Minuten beträgt.

Die Funktionen selbst sind sehr kleine Code-Bits mit minimalen Abhängigkeiten. Ich bin mir nicht sicher, was wir sonst noch tun können, um die Pipeline zu beschleunigen.

Das ist wirklich traurig zu hören. Ein anderer Ansatz besteht darin, mehrere Einstiegspunkte/Routen in einer einzigen Funktion zu bündeln. Dies ist offensichtlich nicht das Beste aus der Trennung von Bedenken/Größe/Sicherheit, aber das haben wir mit all unseren API-Endpunkten (einzelner Einstiegspunkt, der dann einen internen Router verwendet) gemacht und seitdem nicht viele Kontingentbeschränkungen erlebt (aber sie kommen gelegentlich vor).

Dennoch scheint diese Kontingentgrenze sehr niedrig zu sein, da das offizielle Dokument „80 pro 100 Sekunden“ für „Aufrufe zum Bereitstellen oder Löschen von Funktionen über die Cloud Functions-API“ auflistet. Ich nehme an, der Google-Support konnte dieses Limit nicht noch weiter erhöhen?

Dennoch scheint diese Kontingentgrenze sehr niedrig zu sein, da das offizielle Dokument „80 pro 100 Sekunden“ für „Aufrufe zum Bereitstellen oder Löschen von Funktionen über die Cloud Functions-API“ auflistet. Ich nehme an, der Google-Support konnte dieses Limit nicht noch weiter erhöhen?

@dinvlad Ich habe mich sowohl beim Vertrieb als auch beim Support erkundigt, ob dieses API-Limit erhöht werden soll. Es ist im Abschnitt "Kontingente" der GCP-Konsole explizit deaktiviert / ausgegraut. Schließlich gelang es mir, einen Google-Techniker für Hangouts zu gewinnen, der mir mitteilte: „Diese Quote ändert sich nicht“ … also denke ich nicht.

Wir haben .git in der nächsten Version zur Standard-Ignore-Liste hinzugefügt:
https://github.com/firebase/firebase-tools/pull/2395

Das sollte Veröffentlichungen für einige beschleunigen. Natürlich können wir (das Firebase CLI-Team) nicht viel gegen die Latenz im Cloud Functions-Back-End tun.

Stellen Sie sicher, dass Sie firebase deploy --only hosting , wenn Sie keine Funktionen aktualisieren

Hier drüben haben wir auch verwandte Funktionen in einer Funktion gruppiert, sodass es am Ende wie „eine Funktion pro Funktionsbereich“ und nicht wie „eine Funktion pro einzelnem Funktionsgranulat“ aussieht.

Die Leistungsmerkmale der Bereitstellung bestimmen stark die Architektur dessen, was in eine Funktion einfließt!

Wann und warum wurde dieses Problem geschlossen. Es wurde im November 2017 eröffnet und es sieht so aus, als ob es immer noch genauso ein Problem ist wie damals. Ich kann hier keinen Verweis auf "Geschlossen" sehen und würde mich interessieren, warum es geschlossen wurde.

Ich beschwere mich nicht, wundere mich nur. Ich bin mir sicher, dass daran gearbeitet wird, aber es wäre gut, über Fortschritte Bescheid zu wissen.

@chriscurnow wurde geschlossen, weil die eigentliche Ursache anscheinend auf der (Closed-Source-)Serverseite und nicht auf den CLI-Tools liegt, obwohl es sich für Endbenutzer als CLI-Problem manifestiert (per @samtstern in https://github.com /firebase/firebase-tools/issues/536#issuecomment-572830647).

Leider gibt es keinen guten öffentlichen Tracker für das Backend, also bekommen wir hier Updates :(

Wie können wir diesen Fehler für Google öffnen, um ihn in ihrem Backend zu beheben?
Es ist lächerlich langsam

Was bringt es überhaupt, Firebase-Funktionen zu verwenden, wenn es so lange dauert

Hey Leute, vielleicht könnten wir alle dieses Problem bei Google melden und vielleicht hören sie zu?
https://firebase.google.com/support/troubleshooter/contact

Jedes Mal, wenn ich versuche, etwas von Google für etwas Wichtiges zu verwenden, werde ich daran erinnert, dass sie eines der am wenigsten verbraucherfreundlichen Unternehmen sind, aber hey, wir könnten es versuchen.

@RenFontes Ich habe gerade den Fall 00075974 eingereicht: Die Bereitstellung von Firebase-Funktionen ist so langsam, dass sie mit der Firebase-Unterstützung unbrauchbar ist. Ich werde diese Nachricht mit dem aktualisieren, was sie zurückbringen.

Es ist möglich, bestimmte Funktionen bereitzustellen. Könnte die CLI nicht einen "Prüfsummen-Tracker" für jede Funktion haben und nur die geänderten bereitstellen (und auch alles verfolgen, was sie verwendet: Vars, Pakete, ...)?

@SrBrahma sicher, aber das Problem ist auch dann noch vorhanden, wenn Sie nur eine einzelne Funktion bereitstellen (z. B. kann die Bereitstellung einer einzelnen Funktion aufgrund einer Zeitüberschreitung immer noch fehlschlagen).

Es sollte nicht Aufgabe des Benutzers sein, die Bereitstellung der Stapelfunktion zu verwalten, und in vielen Fällen sind Funktionsaktualisierungen atomar erforderlich und können daher nicht aufgeteilt/gestapelt werden.

Schätzen Sie die Vorschläge für eine Problemumgehung, aber was wir hier wirklich brauchen, ist ein SLA von Google und deren Einhaltung.

Es ist wahr, dass Firebase-Funktionen manchmal? (vielleicht oft) an der Leistung scheitern.. Es ist wirklich langsam.. Sie sollten lieber Rust unterstützen.. Geht? ist es viel schneller als Node?

Warten Sie immer noch darauf, dass Google die Bereitstellungszeit von Google Functions verbessert, oder?
Der Wechsel von PWA zu SSR zwang mich, bei jedem Deployment 7 Minuten länger zu warten 😞