Willkommen im EGroupware-Community-Forum.
Bitte beachte: Bedienungsanleitung Forum, EGw-FAQ und richtig posten.
Folge uns: 
Welcome to the EGroupware community forum.
Please note: User manual Forum, EGw-FAQ and post correctly.
Follow us:
Ja es gibt Ausgaben, bei “1” klicke ich auf den Ordner und bei “2” sind die Mails noch nicht geladen (Kasten komplett leer).
Was mir aufgefallen ist (eigentlich keine Überraschung) das json.php aus dem Screenshot oben
braucht für […]\Widget\Nextmatch::ajax_get_rows so lange. Das sind vermutlich die Mails, ich frage mich nur
ob sich das beschleunigen lässt.
Hier mal ein Vergleich zwischen EGroupware und Horde (ja ich weiß die Technik lässt sich nicht vergleichen!).
Es ist der selbe IMAP User/Server, ich kann den IMAP Server also ausschließen.
Es gibt einige Verbesserungen von Ralf welche für ein schnelleres wiederholtes laden sorgen.
Wer das testen mag kann die folgenden Patche einspielen:
Hi Samuel.
Ich habe eine Konstellation, wo ich 21.1 und 23.1 gut vergleichen kann. Da habe ich denselben Mail-Server hinter.
Ich sehe schon, dass der Ordnerwechsel im Vergleich mit der 23.1 etwas länger dauert.
Nun habe ich Patches eingespielt. Das reagiert nun wie ich es aus der 21.1 gewohnt bin, also im Vergleich gleich.
Das ganze hat mit der Verwendung von Avataren/Bildern zu tun. Ist etwas unglücklich programmiert gewesen. Das machte sich um so bemerkbarer, um so mehr Kontakte du im Adressbuch hast (in der DB insgesamt). Bei meiner privaten EGw mit ~1000Kontakten fiel das noch nicht so sehr auf. Auf dem oben genannten Vergleichssystem liegen ~8000 Kontakte. Da war das deutlicher zu spüren.
Wir hatten aber auch einen Kunden mit dem Thema. Mit 80.000 Kontakten…
Wie ist nun deine Erfahrung? Mit wie vielen Kontakten?
Stefan
Hallo Stefan,
wir haben nur 45 (!) Kontakte im Adressbuch, trotzdem fühlt sich der Ordnerwechsel träge® an.
Man sieht mit den Patches ein deutlich Verbesserung, aber knapp ~900ms dauert es immer noch.
Vielleicht ergibt sich noch die ein oder andere Idee an der Performance zu schrauben.
Das ist aktuell “normal”.
Damit wird das im allgemeinen akzeptiert. Liegt im oberen Bereich, Grenze ziehe ich bei 1 Sekunde. Ist im Grunde ein allgemeingültiger (Grenz-)Wert, welcher auch bei Webseiten gilt.
Aus meiner Erfahrung mit vielen persönlich betreueten Anwendern ist das so nie ein Thema gewesen.
Weitere Änderungen werden im Rahmen von Umbauarbeiten folgen. Das dauert aber noch.
So etwas hängt aber auch eben an viele Dingen, Stellen, Schräubchen, …
Der Browswer und das Benutzer-System spielen aber durchaus auch eine Rolle. Mit FF, altem PC und knappen RAM (und vielen Tabs) bekommt man das zu spüren. Da unterscheiden sich aktuellere JS-lastige Anwendungen wie EGroupware von älteren HTML-Frontends ganz erheblich.
Stefan
Hab die Patches auch mal eingespielt und vorher und nachher getestet. Danach besser, Danke!
Hab das mal mit dem Webinterface von All-Inkl.com1 verglichen. Wenn ich dort 120 Mails/Seite einstelle, ist die Reaktionszeit identisch mit EGw ~1s. Bei weiniger Mails reagiert es schneller, bei mehr Langsamer.
Wie viele Mails lädt EGw auf den ersten Schwung?
Sehe ich nicht unbedingt so.
Mit einer gescheiten Mail-Server-Anbindung lädt der die nächsten Kopfzeilen ausreichend schnell nach.
In welchen Situationen bringen 50 geladene Kopfzeilen mehr wie 25?
Maßstab sollte die maximale Anzahl in der
Dann komme ich auf 25.
Ich würde vorschlagen erst einmal die 25 fest ein zu stellen.
Stefan
Bei der Rechnung stimme ich dir zu, es kommt aber darauf an ob die letzten 25 Nachrichten einem Tag entsprechen oder zwei Wochen.
Aber ja ich würde auch mit 25 Nachrichten mitgehen, der Vorteil überwiegt.
Ein schnelles Webinterface ist sehr wichtig für die Akzeptanz der Anwender.
Wir haben jetzt die Performance der Mail Liste nochmal verbessert:
Die Commits können in eine aktuelle 23.1 eingespielt werden:
curl https://github.com/EGroupware/egroupware/compare/c8bee10afc...ef06967f85.patch | docker exec -i egroupware patch -p1 -d /usr/share/egroupware
docker exec -it egroupware bash -c 'cd /usr/share/egroupware && npm run build && kill -s USR2 1'
Wenn man das ganze mit /usr/share/egroupware-sources, statt /usr/share/egroupware wiederholt übersteht es auch Restarts des Containers / Reboots des Hosts.
Bitte mal testen …
Ralf
@RalfBecker
ich hab es jetzt mal versucht, aber der Kill Befehl stimmt scheinbar nicht:
created . in 18.5s
npm notice
npm notice New major version of npm available! 8.19.4 -> 9.7.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v9.7.2
npm notice Run npm install -g npm@9.7.2 to update!
npm notice
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Kannst Du dein Beitrag editieren, da fehlt ein “egroupware” -> docker exec -i egroupware patch
Was ist denn USR2?
Bin mir nicht sicher ob so schon die ganze Wirkung da ist.
Habe die Befehle oben korrigiert
Mit dem USR2 Signal sagt man dem PHP FPM (FastCGI Process Manager), das er einmal neu starten soll, sprich OPCache löschen / geänderte Source laden.
Ralf
Danke @RalfBecker, jetzt hat es geklappt.
Die Performance ist viel besser, beim scrollen sind die Mails mit minimal Verzug da (vorher war immer der Lade-Kreis pro Zeile da).
Auch ein Ordner wechsel fühlt sich jetzt nicht mehr träge an, kam zu glaube was die “kleine Änderungen” ausgemacht haben wenn ich mir das erste Video oben anschaue.
Sehr cool!
Kann es sein das dieser Patch dafür sorgt das die Icons im Status rechts nicht mehr stimmen?
Beispiel:
Max Musterman hat jetzt PS usw.
Mhm ich kann das nicht patchen:
can't find file to patch at input line 14
Perhaps you used the wrong -p or --strip option?
Ist das denn nicht der egroupware Container?
Edit:
Ich glaube der Pfad stimmt nicht im Patch, muss das nicht ./status/templates/default/index.xet sein?
Edit2:
Gefunden 
nicht […] patch -p1 -d /usr/share/egroupware sondern […] patch -p1 -d /usr/share/egroupware/status
eigentlich logisch…