Performance #200
Comments
|
Ich arbeite soeben an einem Teilbereich davon (Karten) |
|
Danke!! Ich bin sicher, am Ende kommt es gut! |
|
Nachdem ich vorher auf dem Kartentool war (Fehlermeldung Zoomen auf aktive TPop) war die Geschwindigkeit der FloraDB extrem viel langsamer. Also so, dass Du nach jedem Klick einfach warten musst, bis sich was tut. Neustart hat nichts genützt. Jetzt gehts wieder, nachdem ich alle Browserdaten gelöscht habe (Google Chrome). Vielleicht hilft Dir das ja für die Fehleranalyse. |
|
Im Moment gebe ich ja nur Kontrollberichte ein. Die Karte hab ich gar nicht mehr offen. Es ist aber schon so, dass man spätestens nach 15 Min den Cache leeren muss, damit man wieder arbeiten kann. Im Westen nichts neues, eigentlich wussten wir das ja schon.. :) Man muss es einfach machen anstatt mit der langsamen Geschwindigkeit weiterzuarbeiten - auch wenn man sich dafür wieder einloggen und neu einrichten muss. |
|
Ich habe soeben:
|
|
Ich merke eigentlich keinen Unterschied. Aber ich kann so mit den regelmässigen Cache-leeren gut arbeiten. |
|
Wenn man auf der Karte Beobachtungen zuordnet, zeigt die Karte extrem viele Daten gleichzeitig an:
Das können mehrere Hundert bis - im Extremfall - mehrere Tausend Objekte sein. Jedesmal, wenn man zuordnet, wird ein erheblicher Teil dieser Daten neu geladen und die Layer neu aufgebaut, weil die Beobachtung den Layer wechselt. Wenn man bedenkt, dass die alte Anwendung es für gewisse Arten nicht schaffte, alle Beobachtungen im Strukturbaum in einer einfachen Liste anzuzeigen (ich musste verhindern, dass mehr als 100 geladen werden), ist es erstaunlich, dass es überhaupt funktioniert. Das verwendete Karten-Werkzeug kommt hier an seine Grenzen. Es gibt alternative Karten-Werkzeuge, die eine andere Technologie verwenden, um Tausende von Objekten effizient(er) anzeigen zu können. Diese andere Technologie hat aber gegenüber der vom jetzt benutzen Kartentool verwendeten Technologie grosse Nachteile. Diese können zwar einigermassen umgangen werden. Aber: der Aufwand für die Programmierung ist immens. Aktuell entstehen Werkzeuge, die diesen Aufwand reduzieren (andere haben dieselben Probleme wie wir). Aber noch ist es zu aufwändig. Mit anderen Worten: weitere Optimierungen sind möglich, aber aufwändig bis extrem aufwändig. Am einfachsten wäre es, die Anzahl auf der Karte darzustellender Objekte zu reduzieren. Wie z.B. in der alten Anwendung, wo die Liste im Strukturbaum nur die 100 neusten anzeigte. Das ist aber auch aufwändig und es gibt bestimmt Probleme, an die wir noch nicht denken. Beispiele:
|
|
@alinemeyer siehe obige Bemerkung von mir (du musst es auf GitHub anschauen) |
|
Ich habe soeben eine ziemlich grosse Änderung live gesetzt. Sie führt dazu, dass die eigentliche Karte (und damit die Hintergrund-Layer) nur noch ein mal geladen wird. Das sollte ihre Performance erhöhen. Momentan fällt mir keine andere Methode ein, um die Performance der Karte zu erhöhen, auch beim Zuordnen. Das Problem der teilweise sehr vielen Objekte, die darauf angezeigt werden (müssen) bleibt (siehe meinen Kommentar weiter oben, nur auf github sichtbar). |
|
Wie anderswo beschrieben enthält das für den Daten-Zwischenspeicher verwendete Werkzeug (react-apollo) offensichtlich Fehler, welche dazu führen, dass die Anwendung je länger desto mehr Arbeitsspeicher beansprucht(e). Das führt zu Langsamkeit, bis hin zu Abstürzen. Nun treten diese Fehler nicht bei allen Anwendungen auf, in denen das Werkzeug verwendet wird. Sonst wären sie schon lange behoben worden. Es müssen also bestimmte Funktionalitäten sein, welche dazu führen, dass es passiert. Darum habe ich in den letzten zwei Wochen mit riesigen Anpassungen (und entsprechenden Nebenwirkungen) alles verändert, was in meinen Augen zu solchem Verhalten führen könnte weil es fortgeschrittene Nutzung ist, d.h. über den einfachsten Fall hinausgeht. Zum Teil habe ich Funktionalitäten abstellen müssen (es gibt Daten, die nicht mehr sofort aktualisieren, z.B. gewisse Auswahllisten). Zum Teil habe ich Funktionalitäten mit anderen Werkzeugen umgesetzt, z.B. das sogenannte "client state". Mir scheint, das hat nun endlich genutzt. Ich kann die zuvor beobachteten Speicher-Zuwächse nicht mehr beobachten. Mittlerweile ist das Verhalten auch anderen Benutzern von react-apollo aufgefallen und mehrere Varianten davon wurden im github-repository von react-apollo beschrieben. Wir können also hoffen, dass die Fehler in den nächsten Wochen oder Monaten behoben werden. Worauf ich dann die abgeschalteten Funktionalitäten hoffentlich wieder einschalten kann. Es war eine riesige Menge Arbeit. Und wegen des grossen Umbaus haben zwischenzeitlich diverse Sachen nicht funktioniert. Und wahrscheinlich gibt es immer noch Sachen, die nicht funktionieren. Das Positive daran: Weil ich den "client state" nochmals neu implementieren musste, konnte ich dessen Implementation verbessern. Ich kann leider die Auswirkungen nicht messen, aber ich glaube, sowohl die Karte als auch der Strukturbaum sind nun spürbar schneller geworden. |
|
Lieber Alex |
|
Lieber Alex |
|
Und du hast recht. Ich habe das aktuelle Verhalten hier beschrieben: apollographql/apollo-client#4210 (comment). Ist also alles andere als befriedigend. Was ich oben gemeint habe ist: Der Speicher wächst nicht mehr in Höhen, welche die Anwendung offensichtlich einfrieren und gar zum Absturz bringen. Aber alles über 500MB ist viel zu viel. Und: filtern reicht. Dabei wird laufend der interne Zwischenspeicher aktualisiert. Meine bisher grösste Hoffnung: Der Comment über meinem im verlinkten Issue bezieht sich auf eine Anwendung, die soeben von Microsoft gekauft wurde (Spektrum). Das ist also nicht irgend eine kleine Sache, es sind hier die Interessen der grössten Software-Firma der Welt betroffen (ja, Microsoft ist jetzt wieder mehr wert als Apple). Ich kann daher nur hoffen, dass sich die Entwickler von apollo-client dadurch veranlasst sehen, die Sache zu priorisieren. Oder dass Entwickler von Spektrum die Sache selber in die Hand nehmen (ist ja open source). Wie gesagt: Die Sache hat mich ca. 3 Wochen ungeplante Arbeit und viel Ärger gekostet... |
|
Daumendrück! |
|
Der zuständige Entwickler hat Verbesserungen realisiert. Ich habe nun die direkt Aktualisierung abhängiger Daten wieder eingeschaltet, d.h. wenn man Listeneinträge aktualisiert, sollten sie in allen Auswahllisten direkt aktualisiert sein. Der Zwischenspeicher wächst für meinen Geschmack immer noch zu stark an, bevor er dann wieder reduziert wird. Aber hoffen wir, dass es auch über die direkten Aktualisierungen hinaus etwas gebracht hat. |
|
Habe den Viel Glück mit der weiteren Entwicklung, LG von Spectrum |
|
@mxstbr vielen Dank! Ich hoffe, du findest über Weihnachten/Neujahr ein paar ruhige Tage, um sie auf den Skiern verbringen zu können |
|
Hallo Alex |
|
@csalzmann @alinemeyer @csalzmann @kmarti Was Rebecca oben beschreibt ist ziemlich übel. Ist das die Art, wie für euch apflora.ch im Normalfall funktioniert? Wie oft funktioniert es so schlecht? Wie funktioniert es im Durchschnitt? |
|
Es kommt immer drauf an, was man macht oder gemacht hat. Bei mir ists jetzt grad wieder recht übel. Und ich bin ziemlich sicher, es liegt, wie schon auch früher vermutet, am Kartentool. |
|
Ich hab jetzt diverse Male auf unterschiedliche TPops gezoomt. Der von apflora in beanspruchte Speicher blieb recht stabil unter 100MB. Hast du jeweils zwischendrin gefiltert? Oder: wie suchst du die jeweils nächste Teilpopulation? |
|
Bei mir geht es auch etwa 10 Sekunden, dass wenn ich nach einer Art gefiltert habe, die Populationen angezeigt werden und man weitermachen kann. Ich habe aber nur den Strukturbaum und die Daten offen, also keine Karten. |
|
Wenn du eine neue Art wählst, werden deren Daten geladen. Das können wegen der Beobachtungen tausende von Datensätzen sein. Da ist eine Wartezeit leider nicht zu verhindern |
|
Ich habe jetzt gerade den Cache geleert, und ich muss nach Laden der Art (da habe ich total Verständnis) 10 Sekunden warten, bis mein eingetippter Text im Populationsfilter erscheint (da hingegen spinnt doch etwas ;) ). |
Was meinst du damit? |
Wenn ich es richtig verstehe, machst du folgendes:
Dabei wirst du von der Tatsache gebremst, dass die Anwendung nicht reagiert, weil sie noch die Daten lädt. Leider äussert sich dass darin, dass dein getippter Text erst nach dem Laden der Daten erscheint. Dieses Verhalten ist in Web-Applikationen sehr schwierig zu ändern. Aber ihr habt Glück: Wir benutzten React. Und React wird in einem der nächsten Updates Benutzereingaben (Euer Tippen im Filter-Feld) Priorität über andere Prozesse (z.B. das Laden der Daten) geben. Ihr werdet ab dann sofort sehen, was ihr Tippt. Das Ergebnis der Filterung wird natürlich erst nach dem Laden aller Daten erscheinen. Aber es wird viel Benutzer-freundlicher sein. |
|
Okay, also dass das Laden der Daten etwas Zeit braucht verstehe ich auch. |
|
Alex, reden wir wirklich vom gleichen? Alex, könntest Du bitte mal spezifisch schauen bei der Suche rsp. Filter. Bsp. Saxifraga. Gibst Du bei Populationen etwas ein zum suchen (z.B. Wingert) und schaust, wie lange das geht. Bei mir geht das 12 Sekunden, mit frisch geleertem Cache, bis ich das Eingetippte im Feld überhaupt sehe. Der Klassiker: man hat am Schluss den Text 2 oder 3x eingegeben (siehe Screenshot ). |
|
und wenn ich die zuviel geschriebenen Buchstaben rückwärts löschen will, geht das auch nur verzögert. |
Nur, wenn der Server überlastet ist. Und das war in den letzten 7 Tagen nie der Fall: |
|
Danke :)) |
Ein paar Versuche, das zu beantworten:
|
Gute Frage aber das ist nicht möglich. Ich muss das selber provozieren können, um das Problem besser zu verstehen. |
|
Zur Info: Performance ist ein wichtiges Anliegen. Daher arbeite ich im Hintergrund an weiteren Anpassungen, welche sie erhöhen sollten. Es geht darum, die Abfragen für den verwendeten Cache zu optimieren. Ist aber viel Arbeit und daher wird es je nach anderen Projekten ein paar Tage bis Wochen dauern, bis das live geschaltet wird. |
|
Heute ist alles recht verzögert. Rechte Mausklick-Menüs kommen spät und/oder bleiben dann hängen (hab ich auch schon mal gemeldet) Es ist ein bisschen unspezifisch, aber generell hat man das Gefühl, es wird wohl sehr viel gerechnet im Hintergrund. Ich wollte es Dir einfach melden, vielleicht siehst Du ja einen Zusammenhang mit Deinen Arbeiten. Generell scheint mir langsam, es hätte mit der Suche& Filter zu tun, resp. seit Du diese ausgebaut hast. Morgen sitzen wir ja zusammen:). Ich fände es interessant von Dir zu hören, was Du für welche Funktionen als "normale" Wartezeit betrachtest. |
|
Ab sofort laden Populationen und nicht beurteilte Beobachtungen einen Schritt später: Erst, wenn man ihren Ordner öffnet. Bisher wurden sie schon geladen, wenn der AP geöffnet wurde. Grund: Die teilweise lange Dauer verkürzen, die bisher verstrich, wenn man den AP-Ordner öffnete, bis alle benötigten Daten geladen waren. Das funktioniert nur, wenn auf Populationen/Beobachtungen kein Filter gesetzt wurde. Wenn ein Filter gesetzt wurde, laden sie wie bisher, wenn der AP-Ordner geöffnet wird. Grund: Damit die Anzahl Pop/Beob gefiltert werden kann. |
|
Ich habe soeben ein Update live geschaltet, das bei den Formular-Filtern das eigentliche Filtern 100% an die Abfragen auslagert. Damit muss die Anwendung viel weniger selber rechnen. Ausserdem zeigt das Filter-Formular nun auch die Anzahlen (gefiltert und total) des aktiven AP's an (bisher nur des ganzen Projekts). Ich würde das gerne auch für den Strukturbaum-Filter machen. Leider bezieht er sich auf den Label, das heisst auf den Inhalt zweier vereinigter Felder. Daher geht das leider nicht ohne Nachteile. Beispiel: Aktualisiert man eines der beiden Felder würde der Label im Strukturbaum nicht sofort aktualisiert. Aber ich denk noch mehr darüber nach. |
|
Ich könnte den Strukturbaum-Filter ähnlich dem Formular-Filter leistungsmässig optimieren, wenn wir bereit sind, einen Nachteil zu akzeptieren. Weil Tempo ein Problem ist, tendiere ich dazu, das zu machen. Der Nachteil ist: Heute kann man bei Populationen im Filterfeld die Nummer und den Namen der Population kombiniert filtern. Man kann z.B. Künftig könnte man die Nummer und den Namen nicht mehr kombinieren. Man kann als Das trifft überall zu, wo im Label (= dem Namen im Strukturbaum) der Inhalt mehrerer Felder kombiniert wird. Beispiele: EK, EFK, Berichte, Massnahmen-Berichte. Ich könnte die Anwendung so machen, dass sie sofort eine Meldung anzeigt, welche besagt, dass die Kombination beider Felder nicht gefiltert werden kann, wenn jemand den Doppelpunkt ( Bitte sagt mir möglichst rasch, wenn euch dieser Nachteil problematisch erscheint. Ansonsten werde ich das umsetzen. Denn mir scheint, der Strukturbaum-Filter bringt die CPU (den Prozessor) ins Schwitzen. |
|
Hm. Ich kann sogar die Eingabe am Doppelpunkt trennen und den Filter auf die beiden Felder verteilen. Sollte funktionieren. Dann wäre nicht einmal ein Nachteil damit verbunden :-) |
|
Ich glaube, ich habe herausgefunden, wie die Performance auf elegante Weise stark gesteigert werden kann :-) |
|
Lieber Alex
Das wäre natürlich super!!
Herzliche Grüsse
Karin
---------------------------------------------------------------
Karin Marti
Dr.sc.nat.ETH
topos Marti & Müller AG
Idastr. 24
8003 Zürich
Tel. 044 451 52 55
[email protected]
… Am 31.03.2019 um 00:31 schrieb Alexander Gabriel ***@***.***>:
Ich glaube, ich habe herausgefunden, wie die Performance auf elegante Weise stark gesteigert werden kann :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#200 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJuIH_Q_suNuILM1MFP2dlnqLMQDj6DLks5vb_O3gaJpZM4Y7xnv>.
|
|
Es wird definitiv schneller. Ist aber viel Arbeit, daher werden die Fortschritte nach und nach live geschaltet. |
|
Merkt ihr etwas? |
|
Ich hab das Gefühl, es hat viel gebracht. Bin aber gespannt, wie ihr das erlebt. Bin immer noch daran, weitere Verbesserungen vorzunehmen, aber ein grosser Teil ist umgesetzt. |
|
Habe heute etwas mit der DB gearbeitet (aber nicht so intensiv und nichts schwieriges). Fand sie arbeitet gut, wäre mir also nicht aufgefallen, dass es lange Wartezeiten etc. gegeben hätte ;-). |
|
Super. Bitte um weitere Rückmeldungen, sobald ihr etwas melden könnt. |
|
Ich habe nochmals etwas gefunden, was die Arbeit, welche die Anwendung leisten muss, stark reduziert :-) Werde es nach und nach einführen. |
|
O.k., ist jetzt umgesetzt. Und ich glaube, es klappt :-) |
|
Ich wollte einfach mal ein positives Feedback geben. Ich finde, die Performance ist wirklich gut jetzt. Habe zwar noch nicht mit den Karten gearbeitet, da kann ich noch keine Aussage machen, was dann passiert. Aber so bin ich sehr zufrieden. Danke! Deine Arbeit hat sich also sehr gelohnt! |
|
Hoi Alex |
|
Hoi Rebecca Ja, da gibt es einen schwerwiegenden Fehler, siehe #373 Ich habe zu langsam reagiert, weil:
Danke für die Meldung. Künftig bitte:
LG, Alex |
|
Hoi Alex Ja, war mir eben nicht ganz sicher ob es ein Fehler ist oder ob einfach die Performance wieder etwas schwächelt. Werde es mir merken und in Zukunft lieber einen Issue zu viel erstellen. Danke und liebe Grüsse |
|
Oh, richtig, ich hatte schon vergessen, wie das mal war und dass man das durchaus verwechseln konnte! |
|
Ich schliesse diesen Issue, weil er seit 1.5 Jahren gelöst zu sein scheint |
Können wir diesen Issue offen lassen? Ist ja nach wie vor ein Problem. Die Datenbank ist so toll, und wir können so viele neue Sachen machen. Aber dass sie so langsam ist, ist einfach so schade. Da macht es weniger Freude, damit zu arbeiten. Wir müssen dran bleiben!
The text was updated successfully, but these errors were encountered: