AgentTicketPrint ist sehr langsam

Hilfe zu OTRS Problemen aller Art
Post Reply
Charburner
Znuny newbie
Posts: 27
Joined: 06 Aug 2021, 12:13
Znuny / OTRS Version: 6.2.2
Real Name: Jens

AgentTicketPrint ist sehr langsam

Post by Charburner »

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
root
Administrator
Posts: 3370
Joined: 18 Dec 2007, 12:23
Znuny / OTRS Version: Znuny and Znuny LTS
Real Name: Roy Kaldung
Company: Znuny
Contact:

Re: AgentTicketPrint ist sehr langsam

Post by root »

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
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 ?
hkais
Znuny expert
Posts: 267
Joined: 16 Apr 2016, 08:55
Znuny / OTRS Version: see in post
Real Name: Hans
Contact:

Re: AgentTicketPrint ist sehr langsam

Post by hkais »

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.
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 Alter und Größe des Tickets scheinen für die Ausführungsdauer keine Rolle zu spielen.
Naja die Anzahl der Artikel, die Artikellängen, das Displayformat und damit die Anzahl der Pages im PDF spielen sehr wohl eine Rolle.
Wieviele pages werden denn angezeigt nach dem Print?
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.
10 cores für Znuny zugeordnet?
Was passiert auf der Guest beim Durckauftrag?
Process?
CPU Auslastung?
IOPS?
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?
schaue auch noch im maria bzw. mysql slows-sql log ob da was relevantes zu finden ist während Du die PDFs generierst.
Elected 2022-06 as an IT Governance Portal Expert. The portal for Znuny, OTRS and OTOBO users
Charburner
Znuny newbie
Posts: 27
Joined: 06 Aug 2021, 12:13
Znuny / OTRS Version: 6.2.2
Real Name: Jens

Re: AgentTicketPrint ist sehr langsam

Post by Charburner »

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.
Johannes
Moderator
Posts: 255
Joined: 30 Jan 2008, 02:26
Znuny / OTRS Version: All of them ^^
Real Name: Hannes
Company: Znuny|OTTERHUB

Re: AgentTicketPrint ist sehr langsam

Post by Johannes »

Hi,

spannender Vergleich. Ich glaube aber Du schießt am Ziel vorbei 8)
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.
Image_1.png
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.
Charburner
Znuny newbie
Posts: 27
Joined: 06 Aug 2021, 12:13
Znuny / OTRS Version: 6.2.2
Real Name: Jens

Re: AgentTicketPrint ist sehr langsam

Post by Charburner »

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
Johannes
Moderator
Posts: 255
Joined: 30 Jan 2008, 02:26
Znuny / OTRS Version: All of them ^^
Real Name: Hannes
Company: Znuny|OTTERHUB

Re: AgentTicketPrint ist sehr langsam

Post by Johannes »

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
Post Reply