Etherpad-lite: Leistungsabfall bei 1.8.0 und neueren Versionen

Erstellt am 26. Aug. 2020  ·  27Kommentare  ·  Quelle: ether/etherpad-lite

Beschreibe den Fehler
Leistungseinbußen wurden in Version 1.8.0 eingeführt und können auch in neueren Versionen repliziert werden

Reproduzieren
Schritte zum Reproduzieren des Verhaltens:

  1. Erstellen Sie ein langes Pad (z. B. über 4.000 Zeilen).
  2. Drücken Sie am Anfang des Pads die EINGABETASTE, um eine neue Zeile zu erstellen
  3. Lange Zeit für die Bearbeitung der Änderung

Erwartetes Verhalten
Die Erstellung der neuen Zeile durch Drücken der EINGABETASTE sollte viel schneller erfolgen. Als Basis können wir die Version 1.7.5 verwenden.

Screenshots

1. Die alte Art, mit der Iframe-Höhe umzugehen

Dies ist der Code, von dem ich annehme, dass er die Höhe des Iframes "ace2_inner" in Versionen älter als 1.8.0 geändert hat
Screen Shot 2020-08-26 at 10 50 48
https://github.com/ether/etherpad-lite/blob/1.7.5/src/static/js/ace2_inner.js#L4817

2. Der neue Ansatz

Wie der Screenshot zeigt, ist im iframe kein Höhenstil definiert. Seine Größe wird durch die Größe von definiert
#sidediv Kinder. Dies ist möglich, weil es Flexbox verwendet.
Screen Shot 2020-08-26 at 12 13 26

3. Video der Ausgaben 1.7.5 und 1.8.4 mit demselben Text

https://youtu.be/LpthRFAH3GM
Bitte versuchen Sie zu hören, wenn ich tippe

Desktop (bitte vervollständigen Sie die folgenden Informationen):

  • Windows, MacOS, Ubuntu
  • Google Chrome Version 84.0.4147.135

Smartphone (bitte vervollständigen Sie die folgenden Informationen):

Ich habe auf keinem Smartphone getestet

Zusätzlicher Kontext

Das Hauptproblem ist auf die Kosten des Reflow zurückzuführen (siehe nächste Sitzung). Dies bedeutet, dass bei komplexeren CSS-Regeln die Verzögerung zunimmt.
Wenn wir #sidediv auf display:none , tritt diese Verzögerung nicht mehr auf, aber wir verursachen ein Problem mit der Größe des "ace2_inner", wie hier geschrieben https://github.com/ether/ etherpad-lite / blob / development / src / static / css / iframe_editor.css # L125
Auf beiden Versionen laufe ich ohne Plugin.

Der im Video gezeigte Chrome Dev-Tools-Bericht für den Betrieb

1.7.5

graph175
functionCall175

1.8.4

Die Renderzeit hat sich stark erhöht.
graph184
_sehen Sie, wie lange die Operation "Layout" dauert_
functionCall184

Einige interessante Artikel zum Thema

  1. https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing

  2. https://gist.github.com/paulirish/5d52fb081b3570c81e3a

  3. https://gist.github.com/paulirish/5d52fb081b3570c81e3a#more -on-Forced-Layout

Serious Bug

Hilfreichster Kommentar

Hallo Leute ! Vielen Dank für diesen sehr klaren Fehlerbericht

Es tut mir leid, dass ich mich gerade sehr auf andere Projekte konzentriere. Ich werde versuchen, mir dieses Ticket nächste Woche genauer anzusehen. Aber wenn jemand versuchen will zu lösen, sei mein Gast !!

Alle 27 Kommentare

Cc @seballot

Wir haben Testberichterstattung für diesen Afaik. Siehe Reaktionsfähigkeits-Frontend-Test.

Das Problem des Reflow ist bei einer großen Anzahl von Knoten leichter zu erkennen.
Ist das einer? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
Es ist kommentiert

Oh Mann, ich werde auskommentieren und sicherstellen, dass wir eine funktionierende Testabdeckung haben. Hoffentlich kann @seballot schnell einen performanten Fix finden :)

danke @JohnMcLear!

Unkommentiert, danke für den wirklich gründlichen und gut zusammengestellten Fehlerbericht. Wird @seballot erneut stoßen: +1:

Noch nicht von @seballot gehört, trotz E-Mail /

Hallo Leute ! Vielen Dank für diesen sehr klaren Fehlerbericht

Es tut mir leid, dass ich mich gerade sehr auf andere Projekte konzentriere. Ich werde versuchen, mir dieses Ticket nächste Woche genauer anzusehen. Aber wenn jemand versuchen will zu lösen, sei mein Gast !!

@seballot nur eine Beule für die kommende Woche, um sicherzustellen, dass Sie etwas Zeit in Ihrem Zeitplan haben, um sich das bitte anzusehen :) Danke!

Hallo !

Ich kann nicht reproduzieren, ich habe ein 6000 Zeilen langes Pad gemacht und es funktioniert gut

Peek 06-09-2020 11-27

Getestet auf Debian 9 -> Chromium 73 & Firefox 68

Warum sehen Ihre Zeilennummern schlecht aus (Nummer 1 wird in Ordnung angezeigt, von Nummer 2 ist sie zu groß und nicht ausgerichtet)?
Könnte es ein Problem in Ihrem lokalen Code sein?
Vielleicht ist der Leistungsabfall nur auf dem Mac? kann jemand anderes es bitte versuchen?

Ich habe noch nicht getestet, kann aber feststellen, dass der Firefox-Reaktionstest fehlschlägt, der früher bestanden wurde. Versuchen Sie den Firefox-Reaktionstest mit No-Skin-Set, um festzustellen, ob er bestanden wurde.

Test bestanden für mich sowohl auf Chrom als auch auf Firefox

image

Ja, es ist auch nur für mich vorbei, also muss ich tiefer graben, aber ich frage mich, ob es für uns vorbei ist, weil wir auf schnellen (ish) PCs sind und Saucenlabors einige Bauern vm aufwirft, um die Aufgabe zu erledigen?

Ich erlebe auch keine Verzögerung bei ff auf Ubuntu

Okay, wenn ich amount in 1600000 ändere (erstellt 8.000 Zeilen), macht sich die Verzögerung für mich bemerkbar.

Versuchen Sie das @seballot , tests/frontend/specs/responsiveness.js line 26

Ich kann jedoch nicht bestätigen, ob dies ein neuer Fehler ist. Es lohnt sich, 1.7.9 oder was auch immer zu überprüfen und sicherzustellen, dass das Verhalten tatsächlich anders ist. Es muss einen Grund geben, warum der Test auf Reaktionsfähigkeit bei etwa 1 km Linien lag.

Es ist auch erwähnenswert, dass die Erfahrung mit Firefox 52 das Problem ist, moderne FF scheint in Ordnung zu sein? Der Reaktionstest stürzt auf FF 52 ab, ist aber in 80 in Ordnung.

Der reaktionsschnelle Test schlägt bei this.timeout fehl. https://github.com/ether/etherpad-lite/pull/4257/files

Nur um mehr Kontext zu geben. Die Tests wurden auf Chrome unter MacOs durchgeführt. Wir konnten den gleichen Fehler auf sehr schnellen Maschinen wie i9, 64 GB RAM reproduzieren.
@seballot könntest du versuchen, am Anfang des Pads zu bearbeiten?
Ich habe gerade einen Windows-Computer mit Chrome ausprobiert und habe die gleiche Verzögerung.
https://video.etherpad.com/p/example_long_pad

Ich habe Firefox wie einen Idioten getestet und werde jetzt Chrome testen.

Okay wow ja das ist schlecht. Ich habe den Betrag in 800000 geändert und die Verzögerung ist schrecklich.

Ich glaube, die Verzögerung nimmt zu, wenn Sie am Anfang des Pads bearbeiten. Wie in der ersten Zeile.

Ich bin mit den Chrome Performance-Tools nicht allzu vertraut, aber das sehe ich, wenn ich versuche, das Pad responsiveness.js zu bearbeiten.
Screenshot from 2020-09-06 16-54-38

Beachten Sie, dass ich nicht die gesamte Layoutzeit wie Sie bekomme?

Ich habe FF auf einem Windows-Computer ausprobiert und habe die gleiche Verzögerung. Verwenden dieses Pads

https://video.etherpad.com/p/example_long_pad
Über den Reflow hängt es ab, welches CSS angewendet wird, Browser, js Code die Auslöser, .... Deshalb habe ich die Tests ohne Plugin durchgeführt. Ich muss den Code des Reaktionstests überprüfen, um zu verstehen, warum ihr in diesen Tests die Verzögerung nicht erkennt.

Hallo ! tatsächlich fängt es mit 8K an zu frieren. Aber ich habe auf 1.7.5 umgestellt und mit dem Pad von 8k friert es gleich ein (ich würde es sogar als das Schlimmste bezeichnen!)

Wie auch immer, es ist eine Tatsache, dass das Etherpad langsam wird, wenn die Pads zu groß sind. Ich glaube nicht, dass es ein kritischer Fehler ist, da der Block nicht zum Schreiben von Büchern gedacht ist, und ich denke, die meisten Leute verwenden ihn für kurzen Text.

Aber ja, wahrscheinlich könnten wir uns verbessern. Aber ich denke, es wird eine schmerzhafte Aufgabe sein :) Ich bin mir auch nicht sicher, ob es nur mit Standard-Layout-Papierkorb zu tun hat, da eine Besonderheit darin besteht, dass Etherpad unterschiedliche Iframes verwendet und wir daher immer Javascript ausführen müssen, um das Layout auszurichten untereinander (zum Beispiel für die Linienhöhe)

Ich würde versuchen, einen Blick darauf zu werfen, aber ich verspreche nichts, weil
1- es scheint nicht sehr lustig :)
2- Ich glaube nicht, dass es ein kritischer Fehler ist

@JohnMcLear Ich habe versucht, jetzt einen Blick darauf zu werfen, aber ich verstehe nicht, dass jede Änderung, die ich an ace2_inner.js vornehme (sogar das Löschen der gesamten Datei), meine lokale Instanz nicht beeinflusst, sie funktioniert immer noch genauso. Was vermisse ich?

ace2_inner.js wird ohne Versionszeichenfolge atm angefordert, sodass sich die URL zu ace2_inner.js nicht ändert und Ihr Browser-Cache verwendet wird. Wenn Sie in settings.json maxAge = 0 setzen und / oder den Browser-Cache deaktivieren, sollte die neue Datei ohne Neustart bereitgestellt werden.

Hi @ webzwo0i ! Danke für deine Hilfe ! Ich erinnere mich endlich, dass ich den Cache von ace2_inner ungültig machen muss, weil er in den Iframe geladen ist ...

(maxAge = 0 hatte übrigens keinen Einfluss)

Ein bisschen spät jetzt, wird morgen schauen!

Ein Trick besteht darin, die geöffnete Registerkarte "Netzwerk" zu verwenden, um das Caching zu deaktivieren.

@joassouza kannst du Sebastians Ergebnisse bestätigen?

OK, fertig ! Eigentlich war es nicht sehr kompliziert, dank @joassouza, der die ganze Arbeit gemacht hat, um sowohl das Problem als auch die Lösung zu finden

und ich bestätige, dass der Fehler nicht mit den letzten Änderungen an der Benutzeroberfläche zusammenhängt, ich denke, er ist schon lange da!

Ich denke, dies kann jetzt mit dem Fix # 4267 geschlossen werden
Nochmals vielen Dank

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen