Apr 2023
14 / 27
May 2023
Jul 2023
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!

itwo
Jun '23

Morgen Stefan,

kann man das schon einstellen oder meinst Du das kommt noch?

itwo
Jul '23

@RalfBecker

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.

itwo
Jul '23
1

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 :slight_smile:
nicht […] patch -p1 -d /usr/share/egroupware sondern […] patch -p1 -d /usr/share/egroupware/status
eigentlich logisch…