Warum dauert das Beobachten von oplog im Meteor / Mongo so viel Zeit?

Question

Warum dauert das Beobachten von oplog im Meteor / Mongo so viel Zeit?

8

Ich habe einen MongoLab-Cluster, der es mir ermöglicht, Oplog-Tailing zu verwenden, um Leistung, Verfügbarkeit und Redundanz in meiner Meteor.js-App zu verbessern.

Problem ist: Seit ich es benutze, brauchen alle meine Publikationen mehr Zeit, um fertig zu werden. Wenn es nur 200ms dauert, ist das kein Problem, aber es dauert oft viel mehr, wie hier, wo ich die Publikation abonniere, die ich beschrieben habe. hier .

Diese Veröffentlichung hat bereits eine zu lange Antwortzeit, und die Beobachtungen von oplog verlangsamen diese auch, obwohl es bei weitem nicht die einzige Veröffentlichung ist, bei der das Beobachten von oplog so lange dauert.

Könnte mir jemand erklären, was passiert ist? Nirgends, wo ich im Internet suche, finde ich eine Erklärung dafür, warum das Beobachten von oplog meine Veröffentlichung so sehr verlangsamt.

Hier sind einige Screenshots von Kadira, um zu verdeutlichen, was ich sage:

Hier ist ein Screenshot von einem anderen Pub / Sub:

Und schließlich, einer, bei dem das Beobachten von Oplogs eine angemessene Zeit in Anspruch nimmt (aber immer noch mein Pub / Sub etwas verlangsamt):

javascript mongodb meteor mongodb-oplog

David Panart 25.02.2016, 17:28

quelle

1 Antwort

Tags und Links javascript mongodb meteor mongodb-oplog

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Android Play Games: Benutzerdefinierte Raumkonfiguration mit flexibler Anzahl von Spielern

score 0 · Answer 1

Oplog Tailing ist sehr schnell. Oplog Tailing ist hier nicht das Problem.

Sie tun wahrscheinlich eine Menge Dinge, die Ihnen nicht bewusst sind, dass Veröffentlichungen langsam sind:

Einzelnes Dokument, gefolgt von Update-Schleifen : Sie führen wahrscheinlich eine Dokumentaktualisierung im Hauptteil eines Collection.forEach -Aufrufs durch. Dies ist unglaublich langsam und der Ursprung Ihrer schlechten Leistung in Methodenkörpern. Jedes Mal, wenn Sie ein einzelnes Dokumentupdate durchführen, das von Hunderten von gleichzeitigen Verbindungen überwacht wird, muss jedes dieser Updates aktualisiert werden. Durch eine Abfrage, die jeweils einzeln von einem Update gefolgt wird, können weder Mongo noch Meteor optimieren, und sie müssen darauf warten, dass jeder einzelne Benutzer bei jeder Änderung aktualisiert wird. Es ist eine doppelt asymptotische Steigerung Ihrer Leistung. Lösung : Überlegen Sie, wie Sie das Update mithilfe von {multi:true} .
Eindeutige Abfragen für jeden Benutzer : Wenn Sie eine einzige Änderung an einem Benutzerdokument vornehmen, das besagt, dass 100 gleichzeitige eindeutige Abonnements mit ihm verbunden sind, werden die Verbindungen seriell benachrichtigt. Das bedeutet, dass die erste Verbindung in 90ms gemeldet wird, während die letzte Verbindung nach 90ms * 100 Benutzern später benachrichtigt wird. Das ist der andere Grund, warum deine observeChanges langsam sind. Lösung : Denken Sie darüber nach, ob Sie wirklich ein einmaliges Abonnement für jedes Benutzerdokument benötigen. Meteor hat Optimierungen für identische Abonnements, die von mehreren gleichzeitigen Sammlungen gemeinsam genutzt werden.
Viele Dokumente : Sie kodieren wahrscheinlich jeden Thread-Kommentar, Post, jede Chat-Nachricht usw. als eigenes Dokument. Jedes Dokument muss einzeln an jeden Client gesendet werden, wodurch einige zusätzliche Kosten entstehen. Dies ist das richtige Schema für eine relationale Datenbank und das falsche für eine dokumentbasierte Datenbank. Lösung : Versuchen Sie, alle Dinge aufzubewahren, die Sie benötigen, um eine Seite für einen Benutzer in einem einzelnen Dokument zu rendern (De-Normalisierung). In Bezug auf den Chat sollten Sie ein einziges "Konversations" -Dokument haben, das alle Nachrichten zwischen zwei + Benutzern enthält.
Die Datenbank ist nicht mit Ihrem Host verbunden : Wenn Sie MongoLab verwenden, befindet sich Ihre Datenbank möglicherweise nicht im selben Datencenter wie Ihr Webhost (ich nehme an, dass es sich um Galaxy oder Modul handelt). Intra-Datencenter-Latenzzeiten können sehr, sehr hoch sein, und dies ist wahrscheinlich die Erklärung für Ihre schlechten Lesezugriffe. Indizes, wie andere Kommentatoren bemerkt haben, könnten eine Rolle spielen, aber meine Wette ist, dass Sie weniger als hundert Datensätze in einer dieser Sammlungen haben, so dass es nicht wirklich wichtig ist.