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:
Liegt bei mir im Bereich von Augenblick bis auch mal 1 Sekunde. OK meine ich.
Die Anzahl Mails spielt auch erst mal keine sonderliche Rolle. Es werden eh immer nur Teile geladen.
Hast du den Mail-Server mit IP oder DNS eingetragen? Oft liegt die Ursache sind so Geschwindigkeits-Sachen im Bereich DNS.
EGw und Mail-Server laufen intern, richtig? Dennoch mal Ping-Zeiten messen? Wo liegst du da?
Was meint denn die Browser-Konsole?
Stefan
Zwar mit DNS (auch intern) aber beide Server sind intern und über 10 GBit verbunden.
root@egw:~# ping mail
PING mail.intern (10.0.0.40) 56(84) bytes of data.
64 bytes from mail.intern (10.0.0.40): icmp_seq=1 ttl=63 time=0.529 ms
64 bytes from mail.intern (10.0.0.40): icmp_seq=2 ttl=63 time=0.593 ms
64 bytes from mail.intern (10.0.0.40): icmp_seq=3 ttl=63 time=0.465 ms
64 bytes from mail.intern (10.0.0.40): icmp_seq=4 ttl=63 time=0.467 ms
^C
--- mail.intern ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3024ms
rtt min/avg/max/mdev = 0.465/0.513/0.593/0.052 ms
root@egw:~#
Muss ich morgen weiter untersuchen, leider für mich learning by doing.
Hallo Stefan,
IP hat wie zu erwarten nichts gebracht, ich denke das Problem liegt in der Art wie das Webinterface aufgebaut ist?
War das in der 21.1 anders? Die kenne ich ja nicht mehr da wir direkt mit der 23.1 gestartet sind.
Wie zu erwarten haben wir einige Ecken und Abläufe die wir ändern müssen, die Reaktionszeit im Mail wird aber von fast allen Benutzer als träge zurück gemeldet (im Vergleiche zu Horde/Roundcube).
Edit:
Die 3 Sekunden oben waren ein Extrembeispiel, wir bewegen uns aber so im 1-2 Sekunden Bereich.
Mach dir bitte auch mal dazu die Browser-Konsole auf und schau mal, ob du Meldungen mit der Verzögerung zusammen bringen kannst.
Stefan
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!