EGroupware Performance Mail IMAP Ordner wechsel

[itwo]

Wir sind noch recht neu bei EGroupware und kommen ursprünglich von der Horde Groupware.

Ich weiß das sich die Technik nicht vergleichen lässt, aber die Performance bei einem Ordner wechsel ist
mit ~ 2,5 Sekunden sehr langsam. Evtl. liegt aber auch ein Konfigurationsfehler auf unserer Seite vor, vielleicht hat jemand eine Idee?

1. = Ordner Entwürfe (2 Mails) komplett geladen
   -> wechsel auf Posteingang klick
   […]
2. = Ordner Posteingang (1159 Mails) komplett geladen

Last auf dem IMAP Server:
load average: 0,13, 0,14, 0,20

Last auf dem EGroupware/Docker Server:
load average: 0,05, 0,02, 0,00

Test mit dem Chromium Version 112.0.5615.121 und Firefox ESR 102.10.0esr

[StefanU]

mit ~ 2,5 Sekunden sehr langsam

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

[itwo]

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?

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:~#

Was meint denn die Browser-Konsole?

Muss ich morgen weiter untersuchen, leider für mich learning by doing.

[StefanU]

Zwar mit DNS (auch intern

Dann trag in den Mail-Konten mal die IP ein. Mal schauen ob das etwas ändert.

Stefan

[itwo]

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.

[StefanU]

Mach dir bitte auch mal dazu die Browser-Konsole auf und schau mal, ob du Meldungen mit der Verzögerung zusammen bringen kannst.

Stefan

[itwo]

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.

[itwo]

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.

[itwo]

Es gibt einige Verbesserungen von Ralf welche für ein schnelleres wiederholtes laden sorgen.

Wer das testen mag kann die folgenden Patche einspielen:

Comparing 52c7429b7f...193cd5cdb3eef14954d2694745a3473a94239d74 ·...

fix Mail\Avatar::getLavatar(): Argument #1 ($address) must be of type string, null given

also allow calling Mail\Avatar::getAvatar() without an email

[StefanU]

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

[itwo]

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.

[StefanU]

~900ms

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

[Rechen-Knecht]

Hab die Patches auch mal eingespielt und vorher und nachher getestet. Danach besser, Danke!
Hab das mal mit dem Webinterface von All-Inkl.com 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?

[RalfBecker]

Wie viele Mails lädt EGw auf den ersten Schwung?

50 Mail, könnte man sicher mal mindestens halbieren.

Ralf

[itwo]

Ich fürchte das ist eine ganz individuelle Einstellung, evtl. den Wert konfigurierbar machen?

[StefanU]

Ich fürchte das ist eine ganz individuelle Einstellung, evtl. den Wert konfigurierbar machen?

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

• 3-Spalten-Ansicht
• (sagen wir mal) Monitor mit 2160px Höhe
• Browser 100%
• Schriftgröße EGw: small

Dann komme ich auf 25.

Ich würde vorschlagen erst einmal die 25 fest ein zu stellen.

Stefan

[itwo]

Maßstab sollte die maximale Anzahl in der

3-Spalten-Ansicht
(sagen wir mal) Monitor mit 2160px Höhe
Browser 100%
Schriftgröße EGw: small

Dann komme ich auf 25.

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.

[RalfBecker]

Wir haben jetzt die Performance der Mail Liste nochmal verbessert:

• die Mail App sucht jetzt nicht mehr (vorab) nach Avatar Bildern
• die Bilder werden (client-seitig) erst mal als Buchstaben angezeigt
• sobald das Bild im Browser sichtbar wird (oder kurz davor) wird der Server nach dem Avatar für die EMail Adresse gefragt

Comparing c8bee10afc...ef06967f85 · EGroupware/egroupware

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

[itwo]

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

[RalfBecker]

Kannst Du dein Beitrag editieren

Habe die Befehle oben korrigiert

Was ist denn USR2?

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