Firestore Problem langsam auf das abrufen von Daten

UPDATE: 12th Feb 2018 - iOS Firestore SDK v0.10.0

Ähnlich wie einige andere Kommentatoren, ich habe auch bemerkt, dass eine langsamere Reaktion auf die erste get-Anfrage (mit nachfolgenden Anforderungen unter ~100ms). Für mich ist es nicht so schlimm, wie 30, aber vielleicht um 2-3s wenn ich eine gute Konnektivität, was genug ist, um eine schlechte user-experience, wenn meine app gestartet wird.

FB hingewiesen haben, dass Sie bewusst von diesem "Kaltstart" - Problem und Sie arbeiten an einer langfristigen Lösung für Sie - keine ETA-leider. Ich denke, es ist ein separates Problem, dass wenn ich die schlechten verbindungen kann es Jahre dauern (über 30s), bevor die get-Anfragen entscheiden, Lesen aus dem cache.

Während der Feuerstellung lösen all diese Probleme, habe ich angefangen mit den neuen disableNetwork() und enableNetwork() Methoden (erhältlich in Firestore v0.10.0) zur manuellen Steuerung des online - /offline-Status von FB. Aber ich habe zu sehr vorsichtig, wo ich es in meinen code, da es eine Firestore Fehler, können einen Absturz verursachen, unter bestimmten Szenarien.

UPDATE: 15-Nov-2017 - iOS Firestore SDK v0.9.2

Scheint es das langsame performance-Problem wurde nun behoben. Ich habe re-führen Sie die unten beschriebenen tests und die Zeit, die für Firestore zur Rückgabe der 100 Dokumente, die jetzt zu sein scheint, sich konsequent um 100ms.

Nicht sicher, ob dies war ein Update, das neueste SDK v0.9.2 oder, wenn es ein backend-Update (oder beides), aber ich schlage vor, alle updates Ihrer FB-pods. Meine app ist deutlich schneller - ähnlich, wie es war auf der Echtzeit-DB.

Ich habe auch entdeckt, Firestore viel langsamer als in Echtzeit DB, vor allem beim Lesen von vielen Unterlagen.

Aktualisierten tests (mit dem neuesten iOS Firestore SDK v0.9.0):

Habe ich ein test-Projekt in iOS Swift mit beiden RTDB und Firestore und lief 100 sequenzielle lese-Operationen auf den einzelnen. Für die RTDB, getestet habe ich die observeSingleEvent und beobachten Sie Methoden auf jedes der 100 top-level-Knoten. Für Firestore, habe ich die getDocument und addSnapshotListener Methoden an jedem der 100 Dokumente in der TestCol Sammlung. Ich lief die tests mit disk Persistenz auf und ab. Bitte Lesen Sie das angehängte Bild, zeigt die Datenstruktur, die für jede Datenbank.

Lief ich den test 10 mal für jede Datenbank auf dem gleichen Gerät und eine stabile wifi-Netzwerk. Vorhandene Beobachter und Zuhörer waren zerstört, vor jedem neuen Lauf.

Realtime DB observeSingleEvent Methode:

func rtdbObserveSingle() {

    let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
    print("Started reading from RTDB at: \(start)")

    for i in 1...100 {
        Database.database().reference().child(String(i)).observeSingleEvent(of: .value) { snapshot in
            let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
            let data = snapshot.value as? [String: String] ?? [:]
            print("Data: \(data). Returned at: \(time)")
        }
    }
}

Realtime DB-beobachten-Methode:

func rtdbObserve() {

    let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
    print("Started reading from RTDB at: \(start)")

    for i in 1...100 {
        Database.database().reference().child(String(i)).observe(.value) { snapshot in
            let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
            let data = snapshot.value as? [String: String] ?? [:]
            print("Data: \(data). Returned at: \(time)")
        }
    }
}

Firestore getDocument-Methode:

func fsGetDocument() {

    let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
    print("Started reading from FS at: \(start)")

    for i in 1...100 {
        Firestore.firestore().collection("TestCol").document(String(i)).getDocument() { document, error in

            let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
            guard let document = document, document.exists && error == nil else {
                print("Error: \(error?.localizedDescription ?? "nil"). Returned at: \(time)")
                return
            }
            let data = document.data() as? [String: String] ?? [:]
            print("Data: \(data). Returned at: \(time)")
        }
    }
}

Firestore addSnapshotListener Methode:

func fsAddSnapshotListener() {

    let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
    print("Started reading from FS at: \(start)")

    for i in 1...100 {
        Firestore.firestore().collection("TestCol").document(String(i)).addSnapshotListener() { document, error in

            let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
            guard let document = document, document.exists && error == nil else {
                print("Error: \(error?.localizedDescription ?? "nil"). Returned at: \(time)")
                return
            }
            let data = document.data() as? [String: String] ?? [:]
            print("Data: \(data). Returned at: \(time)")
        }
    }
}

Jede Methode im wesentlichen druckt die unix-Zeitstempel in Millisekunden, wenn die Methode beginnt mit der Ausführung und druckt anschließend ein anderes unix-timestamp bei jeder lese-operation gibt. Ich nahm den Unterschied zwischen dem ersten Zeitstempel und dem letzten Zeitstempel zurück.

ERGEBNISSE - Disk Persistenz deaktiviert:

ERGEBNISSE - Disk-Persistenz aktiviert:

Datenstruktur:

Wenn die Firestore getDocument /addSnapshotListener Methoden nicht weiterkommen, so scheint es, stecken zu bleiben für die Dauer, die etwa ein Vielfaches von 30 Sekunden. Vielleicht könnte dies helfen, das FB-team isolieren, in denen in der SDK ist es immer stecken geblieben?

Hatte ich dieses Problem bis heute morgen. Meine Firestore-Abfrage via iOS/Swift etwa 20 Sekunden, um eine einfache, vollständig indizierte Abfrage - mit nicht-proportional-Abfrage mal für 1 Element zurückgegeben - den ganzen Weg bis zu 3.000.

Meine Lösung war das deaktivieren von offline-Daten-Persistenz. In meinem Fall, es trifft nicht die Bedürfnisse unserer Firestore-Datenbank - das hat große Teile seiner Daten täglich aktualisiert.

iOS & Android-Nutzer haben diese option standardmäßig aktiviert, während web-Benutzer haben es standardmäßig deaktiviert. Es macht Firestore scheinen wahnsinnig langsam, wenn Sie die Abfrage eine riesige Sammlung von Dokumenten. Grundsätzlich speichert es eine Kopie von, welche Daten Sie Abfragen und je nachdem welche Sammlung Sie gerade Abfragen, ich glaube, es speichert alle Dokumente in), die führen kann zu hohe Speicherauslastung.

In meinem Fall, verursacht es eine riesige warten, für jede Abfrage, bis das Gerät hatte zwischengespeicherten Daten erforderlich - daher die nicht-proportionale Abfrage mal für die steigende Zahl der Elemente zurück, aus der genau die gleiche Sammlung. Dies ist, denn es hat die gleiche Menge an Zeit, um den cache der Sammlung, die in jeder Abfrage.

Offline-Daten aus der Cloud Firestore Docs

Trat ich einige benchmarking zur Anzeige dieser Effekt (mit offline-Persistenz aktiviert) aus der gleichen abgefragt Sammlung, aber mit unterschiedlichen Mengen der Elemente, die zurückgegeben mit der .limit-parameter:

Jetzt bei 100 Elemente zurückgegeben (mit offline-Persistenz deaktiviert), meine Anfrage dauert weniger als 1 Sekunde.

Meine Firestore-Abfrage-code ist unten:

let db = Firestore.firestore()
self.date = Date()
let ref = db.collection("collection").whereField("Int", isEqualTo: SomeInt).order(by: "AnotherInt", descending: true).limit(to: 100)
ref.getDocuments() { (querySnapshot, err) in
    if let err = err {
        print("Error getting documents: \(err)")
    } else {
        for document in querySnapshot!.documents {
            let data = document.data()
            //Do things
        }
        print("QUERY DONE")
        let currentTime = Date()
        let components = Calendar.current.dateComponents([.second], from: self.date, to: currentTime)
        let seconds = components.second!
        print("Elapsed time for Firestore query -> \(seconds)s")
        //Benchmark result
    }
}