Speicherverbrauch/CPU-Last der Adminoberfläche
-
@Homoran Äh, naja, ich habe aber alle Browser durch. Ich bezweifle, dass es Lynx besser läuft :-) Safari und Konquerer kann ich noch testen. Denke aber wegen der Vielfalt der getesteten Browser nicht, dass das etwas ändert.
Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).
@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Die Frage wäre ja mal: Geht es jemand anders auch noch so?
Ja, ich leere dann mal einfach den Cache.
-
@Homoran Äh, naja, ich habe aber alle Browser durch. Ich bezweifle, dass es Lynx besser läuft :-) Safari und Konquerer kann ich noch testen. Denke aber wegen der Vielfalt der getesteten Browser nicht, dass das etwas ändert.
Die Frage wäre ja mal: Geht es jemand anders auch noch so? Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet. Es passiert aber auch so nach einiger Zeit im Hintergrund.
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen? Der Raspberry PI selbst langweilt sich nämlich absolut und hat gar keinen Stress mit den Instanzen. Die SD-Karte sieht auch unauffällig aus (Write/Read Tests haben erwartbare Werte).
@apollon77 Das geht ja hier schneller als in jedem Chat. ;) - also ist das Problem doch irgendwie bekannt? Interessant ist dabei, dass die einzelnen Browser ja nicht alle die selbe JavaScript Engine nutzen. Trotzdem passiert das in allen Browsern. Sprich die Garbage Collection funktioniert nicht, weil noch irgendwelche Variablen irgendwelche Objekte halten, die aber nicht mehr gebraucht werden?
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Verstärkt tritt das Problem übrigens auf, wenn man nebenbei Skripte offen hat und diese startet.
wenn man an den Skripten arbeitet = editiert
Auch das ist bekannt, dass da der Browser Probleme macht, Cache leeren hilft auch da.@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Meint ihr echt, dass die paar Instanzen da den Kohl fett machen?
nein, das Backend hat damit -wie du im Eingangspost richtig festgestellt hast- nichts mit zu tun
-
@Worlik sagte in Speicherverbrauch/CPU-Last der Adminoberfläche:
Die Frage wäre ja mal: Geht es jemand anders auch noch so?
Ja, ich leere dann mal einfach den Cache.
-
Wenn ich mir das Ereignisprotokoll anschaue, dann kommen da sekündlich ~100 Wert rein. Da das in einer endlosen Tabelle gespeichert wird, wundert mich dann da gar nichts mehr. Ich habe den Reiter "Ereignisprotokoll" nun abgeschaltet. Ob das etwas bringt, werde ich dann sehen. Wenn ich die Oberfläche richtig verstehe, werden die zugehörigen Module der Menüpunkte auf der linken Seite erst beim ersten öffnen im DOM-Baum angelegt. Vermutlich bringt das also erstmal gar nichts.
Im Objektbaum werden unter Hierarchien geladen, wenn man sie das erste mal aufklappt. Klappt man sie wieder zu (entweder einzeln oder über den Knopf in der Toolbar) dann werden sie nur ausgeblendet, aber nicht aus dem DOM entfernt. Schlimmer noch: Aktualisierungen werden bei den zugeklappten Knoten weiterhin eingetragen, aber nicht etwa, indem man den Wert der einzelnen Zellen updatet, sondern offenbar durch entfernen der DOM-Knoten und anschließendes Neu einfügen.
Da wundert mich der Performance-Drop absolut nicht mehr. DOM-Knoten löschen und einfügen ist so ziemlich das schlimmste, was man in einer Webanwendung hinsichtlich der Performance tun kann. Ist das eine Sache des FancyTree oder worin liegt das begründet? Es handelt sich ja auch nicht um einen einzelnen DOM-Knoten je Wert sondern eher 30 Stück, weil zahlreiche ungeordnete DOM-Elemente entfernt werden.
Das erklärt auch den weiteren Bug, dass offene Editoren z.B. in der Spalte "Name" hart geschlossen werden, wenn ein neuer Wert rein kommt, während man den Namen anpasst.
Das erklärt aber erstmal nur die CPU-Last und noch nicht den Speicherverbrauch. Entfernte DOM-Knoten sollte der Browser freigeben. In anbetracht dessen, dass ich 64 GB habe und davon 80% frei sind, stört der Speicherverbrauch aber erstmal nicht. Ich habe auch eine Speicheranalyse im Webbrower probiert. Hier sieht man, dass zyklisch Speicher geholt, aber auch zurück gegeben wird. Einen großen Anstieg erzeugt das erstmalige öffnen des Skript Editors (was grundsätzlich zu erwarten und auch okay ist). Die CPU-Last ist aber ein No-Go.
-
Wenn ich mir das Ereignisprotokoll anschaue, dann kommen da sekündlich ~100 Wert rein. Da das in einer endlosen Tabelle gespeichert wird, wundert mich dann da gar nichts mehr. Ich habe den Reiter "Ereignisprotokoll" nun abgeschaltet. Ob das etwas bringt, werde ich dann sehen. Wenn ich die Oberfläche richtig verstehe, werden die zugehörigen Module der Menüpunkte auf der linken Seite erst beim ersten öffnen im DOM-Baum angelegt. Vermutlich bringt das also erstmal gar nichts.
Im Objektbaum werden unter Hierarchien geladen, wenn man sie das erste mal aufklappt. Klappt man sie wieder zu (entweder einzeln oder über den Knopf in der Toolbar) dann werden sie nur ausgeblendet, aber nicht aus dem DOM entfernt. Schlimmer noch: Aktualisierungen werden bei den zugeklappten Knoten weiterhin eingetragen, aber nicht etwa, indem man den Wert der einzelnen Zellen updatet, sondern offenbar durch entfernen der DOM-Knoten und anschließendes Neu einfügen.
Da wundert mich der Performance-Drop absolut nicht mehr. DOM-Knoten löschen und einfügen ist so ziemlich das schlimmste, was man in einer Webanwendung hinsichtlich der Performance tun kann. Ist das eine Sache des FancyTree oder worin liegt das begründet? Es handelt sich ja auch nicht um einen einzelnen DOM-Knoten je Wert sondern eher 30 Stück, weil zahlreiche ungeordnete DOM-Elemente entfernt werden.
Das erklärt auch den weiteren Bug, dass offene Editoren z.B. in der Spalte "Name" hart geschlossen werden, wenn ein neuer Wert rein kommt, während man den Namen anpasst.
Das erklärt aber erstmal nur die CPU-Last und noch nicht den Speicherverbrauch. Entfernte DOM-Knoten sollte der Browser freigeben. In anbetracht dessen, dass ich 64 GB habe und davon 80% frei sind, stört der Speicherverbrauch aber erstmal nicht. Ich habe auch eine Speicheranalyse im Webbrower probiert. Hier sieht man, dass zyklisch Speicher geholt, aber auch zurück gegeben wird. Einen großen Anstieg erzeugt das erstmalige öffnen des Skript Editors (was grundsätzlich zu erwarten und auch okay ist). Die CPU-Last ist aber ein No-Go.
-
@Worlik Wir nehmen gern PRs :-))) Admin 4.x ist inm Branch "4.0.x" ... master Branch ist der React Rewrite Admin 5.0 der in Entwicklung ist
@apollon77 Das freut mich natürlich zu hören. :-) Ich weiß noch nicht, ob ich etwas zum Code beitragen kann. NodeJS ist nicht meine Heimatwelt. Ich erstelle eher eigene Komponenten.
Gibt es das Problem in der nächsten Major denn dann nicht mehr?
-
@apollon77 Das freut mich natürlich zu hören. :-) Ich weiß noch nicht, ob ich etwas zum Code beitragen kann. NodeJS ist nicht meine Heimatwelt. Ich erstelle eher eigene Komponenten.
Gibt es das Problem in der nächsten Major denn dann nicht mehr?
@Worlik In dem Fall hat das ja alles nix mit Nodejs zu tun ... das ist Javascript im Browser :-)
Admin 4 ist JQuery und Material stuff ... Admin 5 wird React.
Ich denke wir brauchen erstmal was "fertiges" von Admin 5, dann kann man mal schauen, aber dadurch das quasi alles ein React rewrite ist ... vielleicht ;-)
-
@Worlik In dem Fall hat das ja alles nix mit Nodejs zu tun ... das ist Javascript im Browser :-)
Admin 4 ist JQuery und Material stuff ... Admin 5 wird React.
Ich denke wir brauchen erstmal was "fertiges" von Admin 5, dann kann man mal schauen, aber dadurch das quasi alles ein React rewrite ist ... vielleicht ;-)
@apollon77 so genau hatte ich noch nicht hingeschaut. 🙈 Freue mich aber natürlich schon mal darauf.
Heißt aber natürlich auch, bis zum Release bleibt das momentane Problem dann erst mal bestehen. Immerhin muss ich nun nicht weiter suchen.
-
@apollon77 so genau hatte ich noch nicht hingeschaut. 🙈 Freue mich aber natürlich schon mal darauf.
Heißt aber natürlich auch, bis zum Release bleibt das momentane Problem dann erst mal bestehen. Immerhin muss ich nun nicht weiter suchen.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden270
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge