Performanceproblem debuggen

[hildeb]

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?

[root]

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

[hildeb]

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:

Code: Select all

CacheTTL => 60 * 60 * 24,

fühlt sich aber nicht schneller an.
2) AgentDashboard ist schneller als AgentTicketQueue (Faktor 2-10)
3) aktive Agenten: 7

[root]

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

[hildeb]

"L" ist es, und in der Tat macht das aktuell einen (nur kleinen) Unterschied.

Bringt

Code: Select all

ReadOnly => 1

irgendwas in Sachen Performance?

[root]

Hi,

Nö, das ist nicht wirklich relevant für die Ansicht. Hast Du was zum Cache gefunden?

- Roy

[hildeb]

Ja, Cache ist mittlerweile an, hat aber nur minimale (positive) Auswirkungen.

[Jay2k1com]

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:

• 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

Während die Seite lädt, hat der

Code: Select all

/opt/otrs/bin/cgi -k start

Prozess 100% CPU, aber es ist kein IO wait zu sehen. Die Datenbank wird auch nicht signifikant belastet.
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

*) auf die 5593 offenen Tickets kam ich per:

Code: Select all

SELECT count(*) FROM ticket WHERE ticket_state_id NOT IN (2,3) AND queue_id = 5;

[hildeb]

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.

[Johannes]

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ß

[Jay2k1com]

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.

[hildeb]

Bonusfrage: Kann ich "leicht" sehen, welche Queues alle Eskalationen aktiv haben?

[zzz]

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:

Code: Select all

SELECT * FROM queue

oder um nur Queues mit einer Eskalationszeit anzuzeigen:

Code: Select all

SELECT * FROM queue 
WHERE first_response_time IS NULL 
   OR first_response_notify IS NULL 
   OR update_time IS NULL

Viele Grüße
Emin