Performanceproblem debuggen
-
- Znuny newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Performanceproblem debuggen
Hi!
Ich habe ein Performanceproblem mit AgentTicketQueu (in 6.5.4).
Das dauert >= 10s um irgendwas anzuzeigen:
INTERFACEANFRAGEN MIN. ANTWORTZEIT MAX. ANTWORTZEIT DURCHSCHNITTLICHE ANTWORTZEIT
AgentTicketQueue 54 0s 10s 4.27s
Auf SQL Ebene habe ich schon slow-query-logging an, dort zeigen sich aber aber keine "Langläufer" (>2s).
Ich vermute, daß irgendein Darstellungs-/Parsingschritt langsam ist, aber frag mich nun wie ich an Timingwerte rankomme.
Liefert aktiviertes Debugging sowas? Und wenn ja: Wohin gehen die Debug-Logs?
Ich habe ein Performanceproblem mit AgentTicketQueu (in 6.5.4).
Das dauert >= 10s um irgendwas anzuzeigen:
INTERFACEANFRAGEN MIN. ANTWORTZEIT MAX. ANTWORTZEIT DURCHSCHNITTLICHE ANTWORTZEIT
AgentTicketQueue 54 0s 10s 4.27s
Auf SQL Ebene habe ich schon slow-query-logging an, dort zeigen sich aber aber keine "Langläufer" (>2s).
Ich vermute, daß irgendein Darstellungs-/Parsingschritt langsam ist, aber frag mich nun wie ich an Timingwerte rankomme.
Liefert aktiviertes Debugging sowas? Und wenn ja: Wohin gehen die Debug-Logs?
-
- Administrator
- Posts: 4114
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceproblem debuggen
Hi,
Frage #1: Haben alle Kundenbackends eine aktive CacheTTL oder stehen die bzw. einige auf 0? Das macht sich besonders bei LDAP-Backends bemerkbar.
Frage #2: Das ist auch auf dem Dashboard so, richtig?
Frage #3: Wieviele (aktive) Agenten sind ca. im System vorhanden?
- Roy
Frage #1: Haben alle Kundenbackends eine aktive CacheTTL oder stehen die bzw. einige auf 0? Das macht sich besonders bei LDAP-Backends bemerkbar.
Frage #2: Das ist auch auf dem Dashboard so, richtig?
Frage #3: Wieviele (aktive) Agenten sind ca. im System vorhanden?
- 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 newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Re: Performanceproblem debuggen
1) "Haben alle Kundenbackends eine aktive CacheTTL?"
Habe nur eines, LDAP und dies hatte KEINEN expliziten Wert für CacheTTL gesetzt.
Ein Blick auf den Code sagt: Keine Angabe von CacheTTL, kein Cache. Nunja.
Jetzt ist es jedenfalls:fühlt sich aber nicht schneller an.
2) AgentDashboard ist schneller als AgentTicketQueue (Faktor 2-10)
3) aktive Agenten: 7
Habe nur eines, LDAP und dies hatte KEINEN expliziten Wert für CacheTTL gesetzt.
Ein Blick auf den Code sagt: Keine Angabe von CacheTTL, kein Cache. Nunja.
Jetzt ist es jedenfalls:
Code: Select all
CacheTTL => 60 * 60 * 24,
2) AgentDashboard ist schneller als AgentTicketQueue (Faktor 2-10)
3) aktive Agenten: 7
-
- Administrator
- Posts: 4114
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceproblem debuggen
Hi,
welche Sicht ist aktiv in AgentTicketQueue? S, M oder L?
Die CacheTTL steht findest Du bei den CustomerUser Konfigurationen. Eigene stehen i.d.R. in der Kernel/Config.pm
So sieht das in der Default.pm aus für das DB-Backend nach einer Setup: https://github.com/znuny/Znuny/blob/dev ... s.pm#L1524
Ähnlich für LDAP, wie gesagt i.d.R. in der Config.pm
- Roy
welche Sicht ist aktiv in AgentTicketQueue? S, M oder L?
Die CacheTTL steht findest Du bei den CustomerUser Konfigurationen. Eigene stehen i.d.R. in der Kernel/Config.pm
So sieht das in der Default.pm aus für das DB-Backend nach einer Setup: https://github.com/znuny/Znuny/blob/dev ... s.pm#L1524
Ähnlich für LDAP, wie gesagt i.d.R. in der Config.pm
- 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 newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Re: Performanceproblem debuggen
"L" ist es, und in der Tat macht das aktuell einen (nur kleinen) Unterschied.
Bringt
irgendwas in Sachen Performance?
Bringt
Code: Select all
ReadOnly => 1
-
- Administrator
- Posts: 4114
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceproblem debuggen
Hi,
Nö, das ist nicht wirklich relevant für die Ansicht. Hast Du was zum Cache gefunden?
- Roy
Nö, das ist nicht wirklich relevant für die Ansicht. Hast Du was zum Cache gefunden?
- 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 newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Re: Performanceproblem debuggen
Ja, Cache ist mittlerweile an, hat aber nur minimale (positive) Auswirkungen.
-
- Znuny newbie
- Posts: 2
- Joined: 30 Jan 2024, 13:12
- Znuny Version: 6.5.1
- Real Name: Robert K.
Re: Performanceproblem debuggen
Bist Du hier mittlerweile weitergekommen? Ich habe ein ähnliches Problem und versuche auch, das irgendwie zu debuggen.
Ich habe allerdings durch einige Tests herausgefunden, dass es nur eine spezifische Queue betrifft, und auch dann nur, wenn man von alt nach neu sortiert und "Alle Tickets" statt "Verfügbare Tickets" auswählt. Je mehr Tickets pro Seite man eingestellt hat, desto schlimmer ist es. Die Queue hat unter diesen Umständen eine Seitenladezeit von ca. 25 Sekunden:
Setting: 50 tickets/page, view "S". Viewing a single queue. Available tickets: 4, all tickets: 141. Measured page load times: Prozess 100% CPU, aber es ist kein IO wait zu sehen. Die Datenbank wird auch nicht signifikant belastet.
Einige Fakten:
Ich habe allerdings durch einige Tests herausgefunden, dass es nur eine spezifische Queue betrifft, und auch dann nur, wenn man von alt nach neu sortiert und "Alle Tickets" statt "Verfügbare Tickets" auswählt. Je mehr Tickets pro Seite man eingestellt hat, desto schlimmer ist es. Die Queue hat unter diesen Umständen eine Seitenladezeit von ca. 25 Sekunden:
Setting: 50 tickets/page, view "S". Viewing a single queue. Available tickets: 4, all tickets: 141. Measured page load times:
- sort by age, oldest ticket first, page 1: avail tickets 2.49s, all tickets 26.46s (!)
- sort by age, newest ticket first, page 1: avail tickets 1.58s, all tickets 6.3s
- sort by ticket no., lowest first, page 1: avail tickets 1.48s, all tickets 25.17s (!)
- sort by ticket no., highest first, page 1: avail tickets 2.98s, all tickets 5.35s
- sort by created, oldest first, page 1: avail tickets 1.65s, all tickets 26.26s (!)
- sort by created, newest first, page 1: avail tickets 1.58s, all tickets 6.03s
- sort by changed, oldest first, page 1: avail tickets 2.38s, all tickets 27.79s (!)
- sort by changed, newest first, page 1: avail tickets 2.43s, all tickets 5.68s
Code: Select all
/opt/otrs/bin/cgi -k start
Einige Fakten:
- kein LDAP
- Cache liegt in Ramdisk
- Index-Modul ist StaticDB
- Article Storage ist Disk
- Wir haben zwei etwa gleich große Queues (was die Anzahl hinter "Alle Tickets" und "Verfügbare Tickets" angeht), nur eine davon hat dieses Problem
- Die problematische Queue hat 5593 offene (= nicht geschlossene) tickets*, insgesamt gibt es davon 12470 über alle Queues
- Die Tickets sind teils recht alt
- Aktive Agenten haben wir ca. 10
- Znuny 6.5.1
Code: Select all
SELECT count(*) FROM ticket WHERE ticket_state_id NOT IN (2,3) AND queue_id = 5;
-
- Znuny newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Re: Performanceproblem debuggen
Nix definitives rausgefunden, aber als wir dann eines der größeren Ticket (Anzahl Attachments, Inhalt) schließen konnten, war die Ladezeit drastisch verkürzt.
Ich gehe von einem Parser-Problem für die Inhalte einer (problematischen) Mail aus.
Ich gehe von einem Parser-Problem für die Inhalte einer (problematischen) Mail aus.
-
- Moderator
- Posts: 397
- Joined: 30 Jan 2008, 02:26
- Znuny Version: All of them ^^
- Real Name: Hannes
- Company: Znuny|OTTERHUB
Re: Performanceproblem debuggen
Hallo,
allgemeine Punkte wurden ja schon besprochen.
Was signifikant Zeit kostet sind offene, speziell alte Tickets bei aktiven Eskalationen.
Die Logik berechnet die Eskalationen immer Live, unter Berücksichtung der Arbeitszeit Kalender.
Das kostet bei einem Ticket was 10 Tage alt ist nicht viel CPU. Bei einem Ticket was 200 Tage alt ist schon wesentlich mehr
und (auch nicht selten) bei Tickets die 1000+ Tage alt sind kann das auch mal, pro Ticket 1-2 Sek. dauern.
Viele Anhänge => viele Artikel => im FS kosten ggf. auch Zeit, wenn das FS nicht schnell genug liefert. Das ist dann aber oft an IO Wait zu erkennen.
Gruß
allgemeine Punkte wurden ja schon besprochen.
Was signifikant Zeit kostet sind offene, speziell alte Tickets bei aktiven Eskalationen.
Die Logik berechnet die Eskalationen immer Live, unter Berücksichtung der Arbeitszeit Kalender.
Das kostet bei einem Ticket was 10 Tage alt ist nicht viel CPU. Bei einem Ticket was 200 Tage alt ist schon wesentlich mehr
und (auch nicht selten) bei Tickets die 1000+ Tage alt sind kann das auch mal, pro Ticket 1-2 Sek. dauern.
Viele Anhänge => viele Artikel => im FS kosten ggf. auch Zeit, wenn das FS nicht schnell genug liefert. Das ist dann aber oft an IO Wait zu erkennen.
Gruß
-
- Znuny newbie
- Posts: 2
- Joined: 30 Jan 2024, 13:12
- Znuny Version: 6.5.1
- Real Name: Robert K.
Re: Performanceproblem debuggen
Danke für die Antworten!
Es war tatsächlich die Kombination alte Tickets und Eskalation. Ich habe in der Queue mal die Eskalationszeiten auf 0 gestellt, und schon ist die alt➜neu Ansicht so schnell wie die neu➜alt.
Es war tatsächlich die Kombination alte Tickets und Eskalation. Ich habe in der Queue mal die Eskalationszeiten auf 0 gestellt, und schon ist die alt➜neu Ansicht so schnell wie die neu➜alt.
-
- Znuny newbie
- Posts: 48
- Joined: 25 Jun 2019, 11:06
- Znuny Version: 6.5.4
- Real Name: Ralf Hildebrandt
- Company: Charite
- Contact:
Re: Performanceproblem debuggen
Bonusfrage: Kann ich "leicht" sehen, welche Queues alle Eskalationen aktiv haben?
-
- Znuny superhero
- Posts: 914
- Joined: 15 Dec 2016, 15:13
- Znuny Version: All
- Real Name: Emin
- Company: Efflux GmbH
- Contact:
Re: Performanceproblem debuggen
Hallo,
wenn es im System viele Queues gibt und man sich nicht durchklicken möchte, kann man im Adminbereich unter „SQL Box“ folgenden Befehl ausführen:
oder um nur Queues mit einer Eskalationszeit anzuzeigen:
Viele Grüße
Emin
wenn es im System viele Queues gibt und man sich nicht durchklicken möchte, kann man im Adminbereich unter „SQL Box“ folgenden Befehl ausführen:
Code: Select all
SELECT * FROM queue
Code: Select all
SELECT * FROM queue
WHERE first_response_time IS NULL
OR first_response_notify IS NULL
OR update_time IS NULL
Emin
Professional Znuny and OTRS services: efflux.de | efflux.de/en/
Free and premium add-ons: German | English
Free and premium add-ons: German | English