Apr 2023
8 / 27
Apr 2023
Jul 2023
itwo
Apr '23

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.

StefanUEGroupware GmbH
Apr '23

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

Stefan

itwo
Apr '23

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.

StefanUEGroupware GmbH
Apr '23

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
Apr '23

Ja es gibt Ausgaben, bei “1” klicke ich auf den Ordner und bei “2” sind die Mails noch nicht geladen (Kasten komplett leer).

Browser Console 2023-04-19_17-10
Browser Console 2023-04-19_17-10.png1900x364 91.4 KB

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.

19 days later
itwo
May '23

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

Wer das testen mag kann die folgenden Patche einspielen:

StefanUEGroupware GmbH
May '23

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
May '23

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.

StefanUEGroupware GmbH
May '23

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
May '23

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?

itwo
May '23

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

StefanUEGroupware GmbH
May '23

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
May '23

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.

1 month later
RalfBeckerEGroupware GmbH
Jun '23
1
StefanU

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

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
Jun '23

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

RalfBeckerEGroupware GmbH
Jun '23

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

itwo
Jun '23

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!