Was versuche ich zu erreichen? Auf der Client-Seite habe ich eine Vielzahl von divs, die einen Fortschrittsbalken anzeigen. Jeder dieser Fortschrittsbalken zeigt einen anderen Status/Level an. Sie werden alle dynamisch aktualisiert. Ich brauche sie weiterhin dynamisch zu aktualisieren, ohne irgendwelche Leistungsprobleme.Synchronisieren mehrerer Fortschrittsbalken auf Clientseite mit Meteor ohne Leistung Problem
Über welche Leistungsprobleme sprechen Sie? Meine Serverseite führt eine Logik aus, die den Status jedes Fortschrittsbalken auf der Clientseite überprüfen kann. Momentan habe ich einen setInterval für eine Zehntelsekunde gesetzt, um die Fortschrittsbalken-Statusstufe zu aktualisieren. Zuerst tat ich dies, indem ich die Daten direkt in einer Mongo-Sammlung aufbewahrte, die ich dann von der Client-Seite zum Aktualisieren der Vorlagen verwendet hatte, indem ich den Status über Vorlagenhelfer zurückgab. Das ist in Ordnung und hat (größtenteils) funktioniert. Wenn ich jedoch eine modale Box (auch eine reaktive modale Box) hinzufügte, die sich auf der bereits laufenden Hauptkörpervorlage mit den dynamischen Fortschritten öffnet, würde sie dramatisch langsamer werden. Die modale Box würde auch einen bestimmten Fortschrittsbalken für das div anzeigen, auf das der Benutzer geklickt hatte.
Lange Rede, kurzer Sinn, der Performance-Effekt war dramatisch und es würde krabbeln. Ich vermutete, dass dies darauf zurückzuführen war, dass der Server so viele Fortschrittsbalken-Aktualisierungen durchführen musste, dass er in der Mongo-Datenbank blieb. Es war einfach zu viel.
Was habe ich versucht, dies zu lösen? Ich entschied mich zu versuchen, die Persistenz der Mongo-Datenbank komplett zu umgehen, um den Status/Level der Fortschrittsbalken zu speichern. Dies wurde durch die Implementierung eines Paketnamens erreicht rocketchat:streamer
Dieses Paket bietet "2-Wege-Kommunikation über DDP". Auf diese Weise konnte ich die Fortschrittsbalkenebenen im lokalen Cache-Array auf dem Server speichern und dann über den rocketchat: Streamer würde die Daten über DDP direkt zum Client schieben. Dies führte tatsächlich zu einer Leistungssteigerung.
Ok, also was ist dein Problem jetzt und warum stellst du diese Frage ein?
Egal, von beiden Strategien erlebe ich immer noch Performance-Probleme und manchmal die Synchronisierung von den verschiedenen angeschlossenen Geräten in meinem Entwicklungsserver nicht die genaue Status synchronisierte Statusleiste erhalten. Ich benötige alle Fortschrittsbalken, um für alle verbundenen Benutzer im Browser immer den gleichen genauen Status anzuzeigen. Ich brauche zum Beispiel 9 verschiedene eindeutige Fortschrittsbalken auf der Vorlage und auch, wenn der Benutzer auf eine der eindeutigen divs klickt, die eine Fortschrittsleiste enthält, um eine weitere einzelne Fortschrittsleiste innerhalb des Modals anzuzeigen.
Jungs, was ist der beste Weg mit Meteor zu erreichen, mehrere verschiedene Fortschrittsbalken auf der Clientseite zu synchronisieren, indem die Daten von der Logik auf dem Server ausgeführt werden?
Ich bin auf der Suche nach einer einfachen und einfachen Möglichkeit, dies zu implementieren. Ich weiß, dass es einen einfachen Weg geben muss, um sowohl Leistung als auch Synchronisierung mit Meteor für diese Art von Anwendungsfall zu haben.
Jede Hilfe würde sehr geschätzt werden.
Vielen Dank an alle in der Gemeinschaft, die. Durch die nicht alle der alten verfallenen Daten gelöst läuten bietet von persistierenden durch die Meteor.publish
Der Punkt, dass Sie nicht auf Probleme stoßen, haben, bis Sie die modal mit dem zusätzlichen Fortschrittsbalken eingeführt ist wahrscheinlich ein wichtiger Hinweis. Dein ursprünglicher Ansatz (update mongo mit Fortschritt, lass Pub-Sub seine Arbeit tun) klingt solide. Wurde der "extra" Fortschrittsbalken zufällig in einem anderen Abonnement behandelt? Haben Sie herausgefunden, ob dies ein Client- oder Server-Problem ist? Wie sieht der Netzwerkverkehr (ws) auf einem Client aus? Aktualisieren Ihre Helfer mehr als Sie erwarten würden, sobald Sie das Modal zeichnen? –
Danke für Ihre Antwort. Ich kam schließlich zu der Lösung, nachdem ich erkannt hatte, dass mein Meteor.publish auf der Serverseite einen Fund zur Sammlung ausführt, aber alle Dokumente zurückgibt, einschließlich Dokumente, die nicht mehr aktiv und benötigt werden. Die Sammlung wuchs weiter und die meisten dieser Daten waren nicht einmal notwendig, da sie nicht mehr aktiv waren. Ich änderte den Fund, um ein $ nin zu machen und nicht die alten abgelaufenen Daten von der Veröffentlichung auf dem Client zu übernehmen. Große Leistungssteigerung. Hier finden Sie auch einen tollen Artikel: https://kadira.io/academy/meteo-performance-101/content/reducing-pubsub-data-usage – jremi