Hallo zusammen,
wir haben seit längerem das Problem, dass die Druckaufbereitung via AgentTicketPrint und darin das Aufrufen des Herunterladen-Dialogs sehr langsam sind.
Nach dem Klick auf "Drucken" dauert es in der Regel mindestens 8 Sekunden bevor die PDF-Ansicht geöffnet wird.
In der PDF-Ansicht dauert es dann mit Chrome nochmal ca. 8 Sekunden bevor der "Speichern unter"-Dialog angezeigt wird.
Mit Firefox klappt zumindest der Download "instant".
Ich meine das war "früher" deutlich schneller.
Alter und Größe des Tickets scheinen für die Ausführungsdauer keine Rolle zu spielen.
Es handelt sich um Znuny 6.2.2, das auf CentOS 7.9 in einer Hyper-V VM mit 10 Kernen und 12 GB RAM läuft.
Das Verzeichnis /opt/otrs/var/tmp wurde in eine 2 GB RAM-Disk (tmpfs) ausgelagert. Den ArticleStorage (ca. 115 GB) haben wir vor einiger Zeit von DB auf FS umgestellt.
Habt ihr eine Idee, woran das liegen könnte und/oder wie ich das analysieren bzw. optimieren kann?
Wurde zufällig etwas an dem Modul oder zugehörigen Scriptdateien geändert?
Danke und viele Grüße
AgentTicketPrint ist sehr langsam
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
-
- Administrator
- Posts: 3965
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: AgentTicketPrint ist sehr langsam
Hi,
also Änderungen die die Performance beeinflussen sehe ich hier nicht:
- https://github.com/znuny/Znuny/commits/ ... etPrint.pm
- https://github.com/znuny/Znuny/commits/ ... tem/PDF.pm
Das Alter ist egal, wohingegen die Grösse (Anzahl der Artikel) schon relevant ist für die Dauer.
- Roy
also Änderungen die die Performance beeinflussen sehe ich hier nicht:
- https://github.com/znuny/Znuny/commits/ ... etPrint.pm
- https://github.com/znuny/Znuny/commits/ ... tem/PDF.pm
Das Alter ist egal, wohingegen die Grösse (Anzahl der Artikel) schon relevant ist für die Dauer.
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
-
- Znuny expert
- Posts: 287
- Joined: 16 Apr 2016, 08:55
- Znuny Version: see in post
- Real Name: Hans
- Contact:
Re: AgentTicketPrint ist sehr langsam
kann ich bestätigen ging in alten OTRS 5.x deutlich schneller. Habe mich aber noch nie darum gekümmert, da es solten vorkommt dass Tickets "gedruckt" werden müssen. Und für die seltenen Fälle...Charburner wrote: ↑14 Sep 2022, 17:38 Hallo zusammen,
wir haben seit längerem das Problem, dass die Druckaufbereitung via AgentTicketPrint und darin das Aufrufen des Herunterladen-Dialogs sehr langsam sind.
Nach dem Klick auf "Drucken" dauert es in der Regel mindestens 8 Sekunden bevor die PDF-Ansicht geöffnet wird.
In der PDF-Ansicht dauert es dann mit Chrome nochmal ca. 8 Sekunden bevor der "Speichern unter"-Dialog angezeigt wird.
Mit Firefox klappt zumindest der Download "instant".
Ich meine das war "früher" deutlich schneller.
Naja die Anzahl der Artikel, die Artikellängen, das Displayformat und damit die Anzahl der Pages im PDF spielen sehr wohl eine Rolle.Charburner wrote: ↑14 Sep 2022, 17:38 Alter und Größe des Tickets scheinen für die Ausführungsdauer keine Rolle zu spielen.
Wieviele pages werden denn angezeigt nach dem Print?
10 cores für Znuny zugeordnet?Charburner wrote: ↑14 Sep 2022, 17:38 Es handelt sich um Znuny 6.2.2, das auf CentOS 7.9 in einer Hyper-V VM mit 10 Kernen und 12 GB RAM läuft.
Das Verzeichnis /opt/otrs/var/tmp wurde in eine 2 GB RAM-Disk (tmpfs) ausgelagert. Den ArticleStorage (ca. 115 GB) haben wir vor einiger Zeit von DB auf FS umgestellt.
Was passiert auf der Guest beim Durckauftrag?
Process?
CPU Auslastung?
IOPS?
schaue auch noch im maria bzw. mysql slows-sql log ob da was relevantes zu finden ist während Du die PDFs generierst.Charburner wrote: ↑14 Sep 2022, 17:38 Habt ihr eine Idee, woran das liegen könnte und/oder wie ich das analysieren bzw. optimieren kann?
Wurde zufällig etwas an dem Modul oder zugehörigen Scriptdateien geändert?
Elected 2022-06 as an IT Governance Portal Expert. The portal for Znuny, OTRS and OTOBO users
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: AgentTicketPrint ist sehr langsam
Hallo zusammen,
ich habe noch ein bisschen mit folgenden Systemen getestet und die Zeiten verglichen:
- Znuny 6.2.2 Livesystem unter Hyper-V (Xeon E5-2650 v2 @ 2.60GHz, VM hat 10 Cores und 12 GB RAM zugewiesen, virt. Festplatte liegt auf SAN-SSDs, CentOS 7.9, MariaDB 10.5)
- Znuny 6.4.2 Testsystem frisch installiert auf Hardware mit allen Daten aus dem Livesystem (2x Xeon E5-2603 v4 = 12 Cores, 64 GB RAM, HDD-Raid 10, Rocky Linux 8.6, Mariadb 10.3)
- Znuny 6.4.2 Testsystem frisch installiert und "jungfräulich" unter Hyper-V (Xeon E5-2650 v2 @ 2.60GHz, VM hat 4 Cores und 4 GB RAM zugewiesen, virt. Festplatte liegt auf SAN-HDDs, Rocky Linux 8.6, Mariadb 10.3)
Was die minimalen Ladezeiten angeht, macht es offenbar keinen Unterschied ob das System virtuell oder auf Hardware läuft.
Selbst bei einem neuen Ticket mit nur 2 Artikeln dauert die Druckaufbereitung mindestens 7-8 Sekunden.
Auch auf einem komplett leeren neuen System sind die Ladezeiten gleich hoch.
Der Speichern-Dialog hingegen, der ja auch nochmal ca. 8 Sekunden benötigt, ist nur in Chrome und Edge langsam.
Im Firefox taucht das Fenster sofort auf. Könnte also ein Chromium-Problem sein (und wäre damit out of scope).
Während der Druckaufbereitung sieht man in top die Zeile "/opt/otrs/bin/c -DFOREGROUND" mit 100 %CPU, in htop dagegen "/usr/sbin/httpd -DFOREGROUND" mit 100 %CPU.
MariaDB slow query logs hatte ich bisher nicht konfiguriert, muss ich mich mal einlesen. Hab es zwar vorhin aktiviert, aber noch bleibt das Log leer.
ich habe noch ein bisschen mit folgenden Systemen getestet und die Zeiten verglichen:
- Znuny 6.2.2 Livesystem unter Hyper-V (Xeon E5-2650 v2 @ 2.60GHz, VM hat 10 Cores und 12 GB RAM zugewiesen, virt. Festplatte liegt auf SAN-SSDs, CentOS 7.9, MariaDB 10.5)
- Znuny 6.4.2 Testsystem frisch installiert auf Hardware mit allen Daten aus dem Livesystem (2x Xeon E5-2603 v4 = 12 Cores, 64 GB RAM, HDD-Raid 10, Rocky Linux 8.6, Mariadb 10.3)
- Znuny 6.4.2 Testsystem frisch installiert und "jungfräulich" unter Hyper-V (Xeon E5-2650 v2 @ 2.60GHz, VM hat 4 Cores und 4 GB RAM zugewiesen, virt. Festplatte liegt auf SAN-HDDs, Rocky Linux 8.6, Mariadb 10.3)
Was die minimalen Ladezeiten angeht, macht es offenbar keinen Unterschied ob das System virtuell oder auf Hardware läuft.
Selbst bei einem neuen Ticket mit nur 2 Artikeln dauert die Druckaufbereitung mindestens 7-8 Sekunden.
Auch auf einem komplett leeren neuen System sind die Ladezeiten gleich hoch.
Der Speichern-Dialog hingegen, der ja auch nochmal ca. 8 Sekunden benötigt, ist nur in Chrome und Edge langsam.
Im Firefox taucht das Fenster sofort auf. Könnte also ein Chromium-Problem sein (und wäre damit out of scope).
Während der Druckaufbereitung sieht man in top die Zeile "/opt/otrs/bin/c -DFOREGROUND" mit 100 %CPU, in htop dagegen "/usr/sbin/httpd -DFOREGROUND" mit 100 %CPU.
MariaDB slow query logs hatte ich bisher nicht konfiguriert, muss ich mich mal einlesen. Hab es zwar vorhin aktiviert, aber noch bleibt das Log leer.
-
- Moderator
- Posts: 393
- Joined: 30 Jan 2008, 02:26
- Znuny Version: All of them ^^
- Real Name: Hannes
- Company: Znuny|OTTERHUB
Re: AgentTicketPrint ist sehr langsam
Hi,
spannender Vergleich. Ich glaube aber Du schießt am Ziel vorbei
Was technisch passiert ist ja zum Glück ersichtlich:
Nach dem Click auf Ticket Print wird das Module ATPrint aufgerufen.
1) Call von TicketGet():
https://github.com/znuny/Znuny/blob/dev ... int.pm#L82
2) Call der Unterfunktion zur PDF Erzeugung:
https://github.com/znuny/Znuny/blob/dev ... int.pm#L99
Mit Referenz zu:
3) https://github.com/znuny/Znuny/blob/dev ... /Ticket.pm
Dort passiert dann die eigentliche Arbeit:
Dort passieren dann mehrere Dinge, davon einige mehr oder weniger Aufwendig:
3.1)
Kunden Daten holen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L171
3.2)
Alter ermitteln und formatieren:
https://github.com/znuny/Znuny/blob/dev ... et.pm#L182
3.3)
Dann folgen verschiedene Basis Funktionen, PDF Objekt an sich erzeugen und Formatierungen
platzieren.
https://github.com/znuny/Znuny/blob/dev ... et.pm#L218
3.4) *Alle* Ticket Infos / Details holen:
_PDFOutputTicketInfos()
https://github.com/znuny/Znuny/blob/dev ... et.pm#L276
3.5) Dynamische Felder und Link Listen holen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L290
https://github.com/znuny/Znuny/blob/dev ... et.pm#L309
3.6) Kunden Infos formatieren und ausgeben
https://github.com/znuny/Znuny/blob/dev ... et.pm#L318
3.7) Article Liste erzeugen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L325
Dann wird das PDF ausgeliefert.
In _PDFOutputTicketInfos() wird dann primär formatiert. Infos sind dann soweit alle
(zum Großteil) schon geholt.
_PDFOutputArticles() hat einiges mehr zu tun.
Du kannst, wenn Du das erforschen magst, gern mal Punkte auskommentieren und dann
entsprechend messen. Es reicht aber auf einer Maschine.
Ich kann sagend das die Layout Ermittlung der PDF Lib nicht optimal ist. Stichwort
Ermittlung von Seiten und Zeilen und dann entsprechend damit umgehen.
Die fassen wir aber momentan nicht an.
Wir spielen intern mit 1-2 Bibliotheken um aus HTML direkt PDF zu erzeugen, das ist
schneller, weil der Rahmen dann schon da ist. Hat aber andere Nachteile.
Zurück zum Thema:
Ich habe mir also die Calls angesehen und kann hier (direkt) keinen Verantwortlichen im eigentlichen
System finden.
Alle "Langläufer" sind System oder PDF API Calls. Und das ist bzw war zu erwarten.
Der Stack sieht in Version 5 übrigens nicht viel anders aus. Allerdings sind die darunter liegenden
APIs und System Calls andere, weil sich im Laufe der Zeit auch die Basis Systeme verändern.
Allein die Fonts und das Rendern dieser dauert verhältnismäßig lange.
Ein Hinweis zum Flamegraph: Um den zu erzeugen muss mod_perl aus sein.
Daher ist die Laufzeit um ein Vielfaches länger als "normal".
Man kann aber die relativen Anteile gut erkennen. Das ist unter mod_perl dann nicht viel anders.
Ist das Logging inaktiv, kommen wir im Schnitt bei 4 Sek. raus. Von Anfrage bis Auslieferung des Requests.
Das ist zwar unser Test Server auf dem mehrere dutzend Systeme laufen, technisch sollte das aber egal sein.
Gruß
P.S.
Ich habe mit einem Ticket mit 10 Artikeln getestet.
Wenn Du es bei einem Ticket provozieren kannst, bräuchte ich da etwas mehr
Details. Wenn ich das nachstellen kann, können wir dann noch einmal schauen.
spannender Vergleich. Ich glaube aber Du schießt am Ziel vorbei
Was technisch passiert ist ja zum Glück ersichtlich:
Nach dem Click auf Ticket Print wird das Module ATPrint aufgerufen.
1) Call von TicketGet():
https://github.com/znuny/Znuny/blob/dev ... int.pm#L82
2) Call der Unterfunktion zur PDF Erzeugung:
https://github.com/znuny/Znuny/blob/dev ... int.pm#L99
Mit Referenz zu:
3) https://github.com/znuny/Znuny/blob/dev ... /Ticket.pm
Dort passiert dann die eigentliche Arbeit:
Dort passieren dann mehrere Dinge, davon einige mehr oder weniger Aufwendig:
3.1)
Kunden Daten holen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L171
3.2)
Alter ermitteln und formatieren:
https://github.com/znuny/Znuny/blob/dev ... et.pm#L182
3.3)
Dann folgen verschiedene Basis Funktionen, PDF Objekt an sich erzeugen und Formatierungen
platzieren.
https://github.com/znuny/Znuny/blob/dev ... et.pm#L218
3.4) *Alle* Ticket Infos / Details holen:
_PDFOutputTicketInfos()
https://github.com/znuny/Znuny/blob/dev ... et.pm#L276
3.5) Dynamische Felder und Link Listen holen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L290
https://github.com/znuny/Znuny/blob/dev ... et.pm#L309
3.6) Kunden Infos formatieren und ausgeben
https://github.com/znuny/Znuny/blob/dev ... et.pm#L318
3.7) Article Liste erzeugen
https://github.com/znuny/Znuny/blob/dev ... et.pm#L325
Dann wird das PDF ausgeliefert.
In _PDFOutputTicketInfos() wird dann primär formatiert. Infos sind dann soweit alle
(zum Großteil) schon geholt.
_PDFOutputArticles() hat einiges mehr zu tun.
Du kannst, wenn Du das erforschen magst, gern mal Punkte auskommentieren und dann
entsprechend messen. Es reicht aber auf einer Maschine.
Ich kann sagend das die Layout Ermittlung der PDF Lib nicht optimal ist. Stichwort
Ermittlung von Seiten und Zeilen und dann entsprechend damit umgehen.
Die fassen wir aber momentan nicht an.
Wir spielen intern mit 1-2 Bibliotheken um aus HTML direkt PDF zu erzeugen, das ist
schneller, weil der Rahmen dann schon da ist. Hat aber andere Nachteile.
Zurück zum Thema:
Ich habe mir also die Calls angesehen und kann hier (direkt) keinen Verantwortlichen im eigentlichen
System finden.
Alle "Langläufer" sind System oder PDF API Calls. Und das ist bzw war zu erwarten.
Der Stack sieht in Version 5 übrigens nicht viel anders aus. Allerdings sind die darunter liegenden
APIs und System Calls andere, weil sich im Laufe der Zeit auch die Basis Systeme verändern.
Allein die Fonts und das Rendern dieser dauert verhältnismäßig lange.
Ein Hinweis zum Flamegraph: Um den zu erzeugen muss mod_perl aus sein.
Daher ist die Laufzeit um ein Vielfaches länger als "normal".
Man kann aber die relativen Anteile gut erkennen. Das ist unter mod_perl dann nicht viel anders.
Ist das Logging inaktiv, kommen wir im Schnitt bei 4 Sek. raus. Von Anfrage bis Auslieferung des Requests.
Das ist zwar unser Test Server auf dem mehrere dutzend Systeme laufen, technisch sollte das aber egal sein.
Gruß
P.S.
Ich habe mit einem Ticket mit 10 Artikeln getestet.
Wenn Du es bei einem Ticket provozieren kannst, bräuchte ich da etwas mehr
Details. Wenn ich das nachstellen kann, können wir dann noch einmal schauen.
You do not have the required permissions to view the files attached to this post.
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: AgentTicketPrint ist sehr langsam
Hallo Johannes,
erstmal vielen Dank für deine Bemühungen und den sehr ausführlichen und aufschlussreichen Beitrag.
Wäre es denkbar dieses Problem zusammen mit allgemeinen Performance-Fragen (viewtopic.php?p=174111) mit euch im Rahmen eines Review Workshops zu analysieren?
Ich bin ab morgen erstmal im Urlaub aber danach werde ich das Thema entsprechend weiterverfolgen.
Gruß
Jens
erstmal vielen Dank für deine Bemühungen und den sehr ausführlichen und aufschlussreichen Beitrag.
Wäre es denkbar dieses Problem zusammen mit allgemeinen Performance-Fragen (viewtopic.php?p=174111) mit euch im Rahmen eines Review Workshops zu analysieren?
Ich bin ab morgen erstmal im Urlaub aber danach werde ich das Thema entsprechend weiterverfolgen.
Gruß
Jens
-
- Moderator
- Posts: 393
- Joined: 30 Jan 2008, 02:26
- Znuny Version: All of them ^^
- Real Name: Hannes
- Company: Znuny|OTTERHUB
Re: AgentTicketPrint ist sehr langsam
Hallo Jens,
ja das geht. Da können wir auch eine solche Analyse durchführen und zusammen prüfen woran es liegt.
Neben der Konfiguration, gibt sicher einige Stellen wo wir code-seitig noch etwas verbessern können.
Einen schönen Urlaub!
Gruß
Johannes
ja das geht. Da können wir auch eine solche Analyse durchführen und zusammen prüfen woran es liegt.
Neben der Konfiguration, gibt sicher einige Stellen wo wir code-seitig noch etwas verbessern können.
Einen schönen Urlaub!
Gruß
Johannes