Performance

[csalzmann]

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!

[barbalex]

Ich arbeite soeben an einem Teilbereich davon (Karten)

[csalzmann]

Danke!! Ich bin sicher, am Ende kommt es gut!

[csalzmann]

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.

[csalzmann]

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.

[barbalex]

Ich habe soeben:

• die Konfiguration für das Zwischenspeichern von Daten kontrolliert und optimiert (hoffentlich)
• die neue Alpha-Version des Werkzeugs, das für den Zwischenspeicher verantwortlich ist, installiert. Es soll schneller sein. Und vermutlich haben sie auch Fehler korrigiert

[csalzmann]

Ich merke eigentlich keinen Unterschied. Aber ich kann so mit den regelmässigen Cache-leeren gut arbeiten. Aline arbeitet an den Beobachtungen zuordnen mit der Karte, und alles ist sehr langsam und drum nicht grad sehr motivierend. Cache leeren nützt ihr eigentlich sozusagen nichts, sagt sie. Also bei der Karte ist def. immer noch ein grösserer Wurm drin. Oder bei den Beobachtungen eher? Oder beidem?

[barbalex]

Wenn man auf der Karte Beobachtungen zuordnet, zeigt die Karte extrem viele Daten gleichzeitig an:

• alle Tpop eines Aktionsplans
• alle Beobachtungen (in bis zu drei Layers)
• ev. auch alle Zuordnungs-Linien

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:

• Es gibt Aktionspläne mit mehreren Hundert Tpop. Wird wohl schwierig, nicht alle anzuzeigen...
• Es gibt offenbar viele Beobachtungen ohne Datum (ein kürzlich korrigierter Fehler basierte darauf)

[barbalex]

@alinemeyer siehe obige Bemerkung von mir (du musst es auf GitHub anschauen)

[barbalex]

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).

[barbalex]

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.

[praktikatopos]

Lieber Alex Vielen vielen Dank für deine Arbeit und die Updates! Die DB ist inzwischen wieder viel schneller! :)

[csalzmann]

Lieber Alex Ich sag es ja ungern. Aber ich merke nicht wirklich viel davon. Aber ich kann nach wie vor arbeiten, sofern ich regelmässig die Browserdaten lösche. Ich gebe im Übrigen jetzt nicht mal viel ein, bin mehr am Daten nachschauen/kontrollieren, filtere rsp. suche viel.

[barbalex]

Und du hast recht.

Ich habe das aktuelle Verhalten hier beschrieben: https://github.com/apollographql/apollo-client/issues/4210#issuecomment-446366207.

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...

[csalzmann]

Daumendrück! Ja es tut mir ja auch mega leid hast Du so viel ungeplante Arbeit mit uns.

[barbalex]

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.

[mxstbr]

Habe den @benjmn ein bisschen gepushed nachdem ich eure Verzweiflung hier gesehen habe, hoffe der Fix hat zumindest etwas geholfen! 👍

Viel Glück mit der weiteren Entwicklung, LG von Spectrum

[barbalex]

@mxstbr vielen Dank! Ich hoffe, du findest über Weihnachten/Neujahr ein paar ruhige Tage, um sie auf den Skiern verbringen zu können

[rebeccakurz]

Hallo Alex Mal wieder eine Bemerkung zur allgemeinen Performance. Ich hatte den Cache bereits geleert. Dann wollte ich bei der Testart Abies alba in einer bestehenden Population eine neue Teilpopulation erstellen. Es passierte nichts. Also habe ich es nochmals versucht. Es passierte wieder nichts. Also nochmals ein drittes Mal versuchen. Wieder nichts. Also habe ich die gesamte Seite aktualisiert und erst dann ist die erstellte TPop erschienen. Allerdings hatte ich gleich 3 neue TPops, da ich es ja dreimal versucht hatte. Also musste ich zwei davon wieder löschen. Alles sehr zeitaufwändig und mühsam...

[barbalex]

@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?

[csalzmann]

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 gebe nichts ein, ich suche nur TPops und zoome auf sie in der Karte. Nach einigen solchen Aktionen wird alles so langsam, dass man wenn man beim Filter etwas schreiben will, es erst nach etwa 10 Sek. Verzögerung das Getippte erscheint, und dass Baum nicht aufgehen will und so. Natürlich hilft es, den Cache zu leeren. Dann gehts wieder recht gut eine Weile. Aber eben nicht sehr lang. Ich müsste jetzt mal Strichli machen, wieviele Suchen ich auf der Karte machen kann. Es liegt ja nicht an der Zeit, sondern an der Aktivität in der Zeit.

[barbalex]

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?

[rebeccakurz]

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.

[barbalex]

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

[csalzmann]

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 ;) ).

[barbalex]

da hingegen spinnt doch etwas

Was meinst du damit?

[barbalex]

ich muss nach Laden der Art (da habe ich total Verständnis) 10 Sekunden warten, bis mein eingetippter Text im Populationsfilter erscheint

Wenn ich es richtig verstehe, machst du folgendes:

1. Art wählen
2. Möglichst bald die Population filtern

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.

[rebeccakurz]

Okay, also dass das Laden der Daten etwas Zeit braucht verstehe ich auch. Aber auch nachdem die Daten schon geladen sind, dauert es lange, bis der eingegebene Text im Filter-Fenster erscheint. Also auch wenn man innerhalb der selben Art nach verschiedenen Populationen filtert. Dann sollten die Daten ja schon geladen sein und es sollte nicht mehr so lange dauern.

[csalzmann]

Alex, reden wir wirklich vom gleichen? Es ist neu, dass das Filtern von Pops so lange geht. Es geht mir wie Rebecca. Wir können es so nicht stehen lassen.

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 ). Ich hatte das Problem zuhause, und jetzt auch hier im Büro.

[csalzmann]

und wenn ich die zuviel geschriebenen Buchstaben rückwärts löschen will, geht das auch nur verzögert. Du müsstest es so machen, dass die Suche zumindest erst nach Return beginnt.

[barbalex]

Aua. Das ist gar nicht gut. Offensichtlich hab ich das bei den falschen Arten getestet, wo das nicht auftrat.

[barbalex]

Du müsstest es so machen, dass die Suche zumindest erst nach Return beginnt.

Guter Vorschlag.

In der Entwicklungsversion beginnt nun die Filterung:

• nach Enter bzw. Return
• wenn man das Filter-Feld verlässt

Es dauert immer noch, bis das Resultat der Filterung sichtbar wird. Aber wenigstens wird das Tippen im Filterfeld nicht mehr beeinträchtigt. Wenn man das erstmalige Laden der Daten abgewartet hat.

[barbalex]

Dass die Filterung an sich lange dauert, muss damit zusammenhängen, dass sie an diversen Orten relativ aufwändige Berechnungen auslöst.

Ich habe nun an ein paar Dutzend Orten diese Berechnungen so angepasst, dass sie ihr Ergebnis cachen. Das heisst: Wird die Berechnung mehr als ein mal mit denselben Variabeln ausgelöst, rechnet sie nicht neu sondern holt einfach das Ergebnis des letzten Mals.

Bin nicht sicher ob das viel bringt, aber vielleicht merkt ihr einen Unterschied.

[csalzmann]

Es wurde doch vorher auch nicht mehr oder anders gerechnet, oder? Es ist schon merkwürdig. Konntest Du denn einen Unterschied finden zwischen den Arten, wo das Filtern schnell ging und langsam? Wieso ist das Filter-Problem auf einmal aufgetaucht?

Es kommt immer drauf an, wieviel man mit der Datenbank arbeitet, ob man Fehler merkt oder nicht. RD sagt mir, dass sie aktuell etwa alle 3 Minuten Cache leeren muss, weil sie einfach viel nachschauen muss in TPops und EKs und so. Cache leeren ist ein Flick, der kann nicht so zum Standard werden.

Ich weiss, Du gibst Dir mega Mühe. Ich hoffe einfach, Du findest etwas, womit Du dem Problem-Lösung noch näher kommst. Die FloraDB hat so Akzeptanz-Probleme.

[csalzmann]

Irgendwie hängt sie einfach. Wollte die Filter-Funkton auf Windows testen. Nach 3-4x Pop- und max 3-4 TPop-Suche ist einfach das Popup-Feld der TPops aufgegangen und stehen geblieben:

Das ist jetzt immer noch da, rudimentär als brauner Strich (hat sich vom Fenster zum Strich geändert, während ich da diesen Text in GitHub schreibe). Gleichzeitig ist die FloraDB eingefroren. Heisst: ich kann klicken was ich will, es passiert nichts. Kriegt man nur mit Reload weg. Das hatte ich auch schon gestern auf Mac, aber nicht gemeldet.

Es kostet halt jedes Mal auch Zeit, wenn man sich nach Reload oder Cache leeren wieder neu einrichten muss.

[barbalex]

Sorry, ich kann das von euch beobachtete Verhalten nicht nachvollziehen.

Ich habe jetzte während 10 Minuten hunderte von Malen gefiltert, auf diversen Ebenen und bei verschiedenen Arten. Es dauerte nie lange. Und der Arbeitsspeicherbedarf lag zwischen 50 und 200MB, meist unter 100MB. Was recht gut ist.

[csalzmann]

Vielen Dank fürs Testen!

Rückfragen:

1. was heisst "nie lange". Von wieviel Sekunden reden wir?

2. Wie gross darf Cache sein? Ich habe nämlich sowieso das Gefühl, dass der gar nie richtig gross ist, und trotzdem langsam. Es aber tatsächlich hilft, den zu leeren. Bitte gib uns da eine Grösse an. Dann testen wir dann auch wieder:).

[barbalex]

ist einfach das Popup-Feld der TPops aufgegangen und stehen geblieben

Das wird ausgelöst, wenn der Browser über dem Strukturbaum ein Klicken der rechten Maustaste registriert. Darüber habe ich keinerlei andere Kontrolle.

Bei mir persönlich gibt es immer wieder Phasen, während denen meine Maus nicht wie gewünscht funktioniert. Momentan kann ich z.B. keine Bereiche markieren, weil das drücken und halten der linken Maustaste irgendwie nicht richtig ankommt. Vielleicht liegt es ja an der Bluetooth-Übertragung...

[barbalex]

was heisst "nie lange". Von wieviel Sekunden reden wir?

Ca. eine Sekunde

[barbalex]

Wie gross darf Cache sein? Ich habe nämlich sowieso das Gefühl, dass der gar nie richtig gross ist, und trotzdem langsam. Es aber tatsächlich hilft, den zu leeren. Bitte gib uns da eine Grösse an. Dann testen wir dann auch wieder:)

Du sprichst von "Cache", ich habe vorhin von "Arbeitsspeicher" gesprochen.

"Cache" wird von Chrome meist für das verwendet, was du in den DevTools (F12 oder cmd+i Tasten drücken) im Reiter "Application" siehst: Eine ganze Reihe von Speichern, die alle etwas gemein haben: Sie sind permanent, weil sie auf einer Festplatte versorgt wurden. Das heisst: Sie überleben einen Neustart des Computers und sie belasten das System nicht. Hier ist es ziemlich egal wie gross sie sind, solange sie nicht die Chrome und dem Betriebssystem zugewiesene maximale Menge überschreiten. Bei mir werden z.B. gerade 49.7 von 65077 MB beansprucht:

Im Gegensatz dazu belastet "Arbeitsspeicher" den Computer direkt. Er ist flüchtig und meist verfügt der Computer über viel weniger davon als über Festplattenspeicher (wo der Cache versorgt wird). Wenn ein Teil des Caches gerade benutzt wird, wird er in den Arbeitsspeicher geladen. Wieviel Arbeitspeicher apflora nutzt siehst du in den DevTools im Register Memory:

Wieviel Arbeitsspeicher belastend wird, hängt vom Computer ab. Bei mir wird es spürbar, wenn der Wert deutlich über 500MB steigt. Wenn der Wert über 1GB steigt, stürzt mein Browser oft ab. Er hat allerdings auch schon Werte über 2GB überlebt.

Schwache Computer und Smartphones reagieren vermutlich bei tieferen Werten.

Auch starke Computer könnten empfindlicher reagieren, wenn andere Prozesse den Computer stark belasten. Wie z.B. ein Virtuelles Windows auf Mac, in dem Chrome läuft.

Es kann auch sein, dass das Betriebssystem sich auswirkt. Denn es ist das Betriebssystem, das entscheidet, wieviel Arbeitsspeicher Chrome erhält.

Solange der beanspruchte Arbeitsspeicher deutlich unter 500MB liegt, sollte es auf einem einigermassen modernen PC eigentlich keine vom Arbeitsspeicher-Verbrauch verursachten Probleme geben. Werte unter 200MB sollten generell unproblematisch sein. Momentan arbeite ich z.B. mit nur drei Apps, habe aber 6 Prozesse, die über 200 MB beanspruchen.

[barbalex]

Irgendwie hängt sie einfach. Wollte die Filter-Funkton auf Windows testen. Nach 3-4x Pop- und max 3-4 TPop-Suche ist einfach das Popup-Feld der TPops aufgegangen und stehen geblieben

Moment mal: Hast du ev. nicht den Strukturbaum-Filter gemeint, sondern den Formular-Filter?

[barbalex]

Ich habe nun mit dem Formular-Filter getestet.

In meinen Tests hat er immer schnell reagiert.

Allerdings baut sich der Arbeitsspeicher recht stark auf. Ich kann also nicht ausschliessen, dass das in gewissen Fällen zu langsamer Reaktion führen könnte.

Der Grund ist folgender: Filter man z.B. nach TPops, soll die Abfrage nicht alle zigtausend TPops vom Server an die Anwendung übertragen sollen. Das wäre extrem ineffizient. Darum filtere ich nicht Anwendungs-seitig sondern übergebe den Filter der Abfrage. Weil die Abfrage filtert, werden nur die benötigten Daten vom Server an die Anwendung übertragen. So weit so schön.

Aber: Das verwendete Werkzeug (apollo cache) speichert das Resultat von gefilterten Abfragen nicht effizient. D.h. die Resultate der Abfrage belegen jedes mal zusätzlichen Platz im Arbeitsspeicher, bis sie wegen Nicht-(mehr)-Gebrauchs wieder herausgeputzt werden (und sie stehen nicht für andere Prozesse zur Verfügung, was hier aber nicht das Problem ist).

Das kann ich leider nicht beeinflussen :-(

[csalzmann]

OK, ich bin jetzt auch wieder da.

Maus, unwillkürliche Fingerbewegungen und Bluetooth. Vielleicht. Aber deswegen muss die FloraDB ja nicht gleich einfrieren. Ist mir eben in 2 Tagen 2x passiert.

[csalzmann]

Ich meinte den Strukturbaumfilter.

[csalzmann]

Also ich komme nicht draus, warum müssen wir Cache leeren, wenn der keinen Einfluss hat? Bis anhin hast Du uns immer das vorgeschlagen.

Wie komme ich im Mac auf diese Einstellungen? Mit CMD + "i" passiert nichts, rsp. es wird was geschrieben (2 Underscores) ?

Ich würde gerne Deine Analysen oben nachmachen und Dir mitteilen, wie das bei uns so aussieht.

Auch Taskmanager weiss ich nicht, wie das geht in Mac für den Arbeitsspeicher.

Wir fragen uns hier manchmal schon, warum es denn bei Dir eigentlich immer besser ist als bei uns. Testest Du wirklich über Browser, oder testest Du so halblokal;)?

[barbalex]

Wie komme ich im Mac auf diese Einstellungen? Mit CMD + "i" passiert nichts, rsp. es wird was geschrieben (2 Underscores) ?

Sorry, ich verwende ausser auf dem Mac immer F12. Daher habe ich vergessen, dass es diese Kombination ist: Ctrl +shift + i. Bzw. auf dem Mac glaube ich: Cmd + shift + i

[barbalex]

Also ich komme nicht draus, warum müssen wir Cache leeren, wenn der keinen Einfluss hat? Bis anhin hast Du uns immer das vorgeschlagen

Cache leeren nützt meistens nichts, um die Performance zu steigern.

Es kann hingegen nützen, um Fehler zu lösen. Wieso? Die App holt sich Werte aus dem Cache. Wenn nun dort drin etwas ist, dass den Fehler auslöst, muss man den Cache löschen, um den Fehler zu beheben.

[barbalex]

Wir fragen uns hier manchmal schon, warum es denn bei Dir eigentlich immer besser ist als bei uns. Testest Du wirklich über Browser, oder testest Du so halblokal;)?

Ich entwickle im Browser mit derselben Anwendung, allerdings im Entwicklungsmodus, wo sie langsamer ist und z.T. (selten) weitere Fehler hat, die ihr nie erlebt, weil viel mehr passiert. Und mit einem lokalen Server statt demjenigen im Internet.

Wenn ihr Fehler meldet, probiere ich das zuerst in der Entwicklungs-Umgebung. Wenn ich es dort nachvollziehen kann, kann ich es dort auch direkt lösen. Wenn ich es dort nicht nachvollziehen kann, teste ich direkt auf apflora.ch. Wenn ich es dort auch nicht nachvollziehen kann, melde ich euch, dass ich es nicht nachvollziehen kann.

Es sind nur ca. 2% der von euch gemeldeten Fehler, die ich direkt auf apflora.ch nachvollziehen kann aber nicht in der Entwicklungsumgebung. Aber es kommt vor und darum teste ich immer auch auf apflora.ch.

[csalzmann]

Ich hab jetzt dann gleich eine längere Besprechung, ich weiss nicht, ob ich heut nochmals dazu komme. Aber wir bleiben dran.

Das CMD+SHIFT+"i" macht auf jeden Fall ein email auf.

Im Moment - ich teste bei Aldrovanda - ist die Performance recht gut. Kann die tagesabhängig sein? Kann es drauf ankommen, ob man alleine an der DB arbeitet oder ob andere auch dran sind?

Produzieren wir denn so viele Fehler mit der FloraDB, dass das Cache leeren immer nützt? Weil es nützt ja wirklich. Müsstest Du dann nicht unseren Cache anschauen, um die Fehler zu finden?

[barbalex]

Das CMD+SHIFT+"i" macht auf jeden Fall ein email auf

Hab jetzt meinen Mac geholt. Es ist: command + option + i (es ist ctrl + shift + i auf Windows...)

[barbalex]

Kann es drauf ankommen, ob man alleine an der DB arbeitet oder ob andere auch dran sind?

Nur, wenn der Server überlastet ist. Und das war in den letzten 7 Tagen nie der Fall: