Performanceprobleme?
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Performanceprobleme?
Hallo zusammen,
ich habe den Eindruck, dass unser Ticketsystem im Laufe der Zeit zu langsam geworden ist.
Sei es die Ticket-Übersicht, andere Ticketansichten oder die Suchfunktion - jeder Seitenaufruf ist träge.
Daher wollte ich euch mal fragen, was man da optimieren kann.
Und ob eure Systeme deutlich schneller sind oder ich vielleicht falsche Erwartungen habe.
Hier mal ein paar Aufrufe, die ich mit der Firefox Netzwerkanalyse gemessen habe:
Aufruf der Übersicht: 4-6 Sekunden
Aufruf eines Tickets aus der Übersicht: 5-7 Sekunden
Ansicht nach Queues: 16 Sekunden
Ansicht nach Status: 10 Sekunden
Ansicht nach Eskalationen: 19 Sekunden
Verschiedene Suchen mit 150-500 Ergebnissen: 6-22 Sekunden
Seitenwechsel in den Suchergebnissen: 8-33 Sekunden
Es handelt sich um Znuny 6.0.34 (vorher OTRS 6 Community), das auf CentOS 7.9 in einer Hyper-V VM mit 6 Kernen und 6 GB RAM läuft.
Das Verzeichnis /opt/otrs/var/tmp wurde in eine 1 GB RAM-Disk (tmpfs) ausgelagert. Den ArticleStorage haben wir vor einiger Zeit von DB auf FS umgestellt.
top:
Ausschnitt SupportDataCollector:
ich habe den Eindruck, dass unser Ticketsystem im Laufe der Zeit zu langsam geworden ist.
Sei es die Ticket-Übersicht, andere Ticketansichten oder die Suchfunktion - jeder Seitenaufruf ist träge.
Daher wollte ich euch mal fragen, was man da optimieren kann.
Und ob eure Systeme deutlich schneller sind oder ich vielleicht falsche Erwartungen habe.
Hier mal ein paar Aufrufe, die ich mit der Firefox Netzwerkanalyse gemessen habe:
Aufruf der Übersicht: 4-6 Sekunden
Aufruf eines Tickets aus der Übersicht: 5-7 Sekunden
Ansicht nach Queues: 16 Sekunden
Ansicht nach Status: 10 Sekunden
Ansicht nach Eskalationen: 19 Sekunden
Verschiedene Suchen mit 150-500 Ergebnissen: 6-22 Sekunden
Seitenwechsel in den Suchergebnissen: 8-33 Sekunden
Es handelt sich um Znuny 6.0.34 (vorher OTRS 6 Community), das auf CentOS 7.9 in einer Hyper-V VM mit 6 Kernen und 6 GB RAM läuft.
Das Verzeichnis /opt/otrs/var/tmp wurde in eine 1 GB RAM-Disk (tmpfs) ausgelagert. Den ArticleStorage haben wir vor einiger Zeit von DB auf FS umgestellt.
top:
Ausschnitt SupportDataCollector:
You do not have the required permissions to view the files attached to this post.
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceprobleme?
Hi,
hier mal zwei Standardfragen dazu:
- Ist der Cache für alle CustomerUser/CustomerCompany Backends an?
- Gibt es viele, und evtl. sogar alte, eskalierte Tickets?
- Roy
hier mal zwei Standardfragen dazu:
- Ist der Cache für alle CustomerUser/CustomerCompany Backends an?
- Gibt es viele, und evtl. sogar alte, eskalierte Tickets?
- 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: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: Performanceprobleme?
Hallo Roy,
alle Kunden, Benutzer usw. sind lokal, also nichts extern angebunden, kein LDAP usw.
(Ich hoffe darauf zielt deine Frage ab)
Der Ansicht nach Ticketeskalationen zufolge würde ich die zweite Frage mit JA beantworten:
Viele Grüße
Jens
alle Kunden, Benutzer usw. sind lokal, also nichts extern angebunden, kein LDAP usw.
(Ich hoffe darauf zielt deine Frage ab)
Der Ansicht nach Ticketeskalationen zufolge würde ich die zweite Frage mit JA beantworten:
Viele Grüße
Jens
You do not have the required permissions to view the files attached to this post.
-
- Znuny superhero
- Posts: 889
- Joined: 15 Dec 2016, 15:13
- Znuny Version: All
- Real Name: Emin
- Company: Efflux GmbH
- Contact:
Re: Performanceprobleme?
Hallo Jens,
Roy hat da einen guten Hinweis gegeben. Das Ausrechnen der eskalierten Tickets läuft unter Znuny leider (noch) relativ langsam.
Durch das Abarbeiten dieser Tickets sollten zumindest die Queue-Ansichten deutlich schneller werden.
— Emin
Roy hat da einen guten Hinweis gegeben. Das Ausrechnen der eskalierten Tickets läuft unter Znuny leider (noch) relativ langsam.
Durch das Abarbeiten dieser Tickets sollten zumindest die Queue-Ansichten deutlich schneller werden.
— Emin
Professional OTRS, Znuny & OTOBO services: efflux.de | efflux.de/en/
Free and premium add-ons: German | English
Free and premium add-ons: German | English
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: Performanceprobleme?
Hallo Emin,
wir treffen nun Maßnahmen um alte offene oder eskalierte Tickets zu schließen.
Gibt es sonst noch Möglichkeiten das System zu beschleunigen?
Zum Beispiel durch Cache-Optimierung, Veränderung der DB-Konfiguration, sonstige Aufräumarbeiten etc?
Wie würdet Ihr die Seitenladezeiten in Anbetracht der SupportData bewerten?
Ist das alles im Rahmen oder stimmt da etwas nicht?
Ich stelle mir vor, dass OTRS/Znuny ja auch in deutlich größeren Unternehmen eingesetzt wird mit viel größerer Anzahl Tickets pro Tag und mehr Daten.
Da müsste die Performance ja noch viel schlimmer sein. Es sei denn wir haben hier die "Grenze" erreicht und nach oben hin tritt dann ein Skalierungseffekt ein. Wenn man bei uns täglich und durchgehend mit dem System arbeitet, braucht man schon eine Menge Geduld![Sad :(](./images/smilies/icon_sad.gif)
wir treffen nun Maßnahmen um alte offene oder eskalierte Tickets zu schließen.
Gibt es sonst noch Möglichkeiten das System zu beschleunigen?
Zum Beispiel durch Cache-Optimierung, Veränderung der DB-Konfiguration, sonstige Aufräumarbeiten etc?
Wie würdet Ihr die Seitenladezeiten in Anbetracht der SupportData bewerten?
Ist das alles im Rahmen oder stimmt da etwas nicht?
Ich stelle mir vor, dass OTRS/Znuny ja auch in deutlich größeren Unternehmen eingesetzt wird mit viel größerer Anzahl Tickets pro Tag und mehr Daten.
Da müsste die Performance ja noch viel schlimmer sein. Es sei denn wir haben hier die "Grenze" erreicht und nach oben hin tritt dann ein Skalierungseffekt ein. Wenn man bei uns täglich und durchgehend mit dem System arbeitet, braucht man schon eine Menge Geduld
![Sad :(](./images/smilies/icon_sad.gif)
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceprobleme?
Hi,
die Performance ist von vielen Faktoren abhängig. Vor allem von der Konfiguration die nicht wirklich technische ist. Ein Beispiel: nutze ich viele Queues um Themen thematisch zu sortieren anstelle von Services o.ä. und nicht um Berechtigungen zu verwenden ist das auch negativ. Bei jedem Ansicht wird für jede Queue die Berechtigung mit beachtet. Und da sich ja tendenziell in den Queues viele= bewegt ist da ein Cache hilfereich, aber nicht die optimale Lösung.
Da fast jedes System anders genutzt wird gibt's kein Patentrezept. An die Datenbank sollte ein richtiger DBA, anhand der Nutzung sollte er gut optimieren können. Den Cache vom Ticketsystem könnte man in eine Ramdisk legen (/opt/otrs/var/tmp/CacheFileStorable).
Die Frage nach den Eskalationen kommt von mir z.B. immer. Je länger ein Ticket eskaliert ist und je mehr es gibt, desto langsamer sind die Übersichten da die Eskalationszeiten immer berechnet werden.
- Roy
die Performance ist von vielen Faktoren abhängig. Vor allem von der Konfiguration die nicht wirklich technische ist. Ein Beispiel: nutze ich viele Queues um Themen thematisch zu sortieren anstelle von Services o.ä. und nicht um Berechtigungen zu verwenden ist das auch negativ. Bei jedem Ansicht wird für jede Queue die Berechtigung mit beachtet. Und da sich ja tendenziell in den Queues viele= bewegt ist da ein Cache hilfereich, aber nicht die optimale Lösung.
Da fast jedes System anders genutzt wird gibt's kein Patentrezept. An die Datenbank sollte ein richtiger DBA, anhand der Nutzung sollte er gut optimieren können. Den Cache vom Ticketsystem könnte man in eine Ramdisk legen (/opt/otrs/var/tmp/CacheFileStorable).
Die Frage nach den Eskalationen kommt von mir z.B. immer. Je länger ein Ticket eskaliert ist und je mehr es gibt, desto langsamer sind die Übersichten da die Eskalationszeiten immer berechnet werden.
- 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 wizard
- Posts: 470
- Joined: 20 Nov 2011, 16:08
- Znuny Version: 6.5.4
- Real Name: Schulmann
Re: Performanceprobleme?
Hallo,Charburner wrote: ↑11 Aug 2021, 12:18 Sei es die Ticket-Übersicht, andere Ticketansichten oder die Suchfunktion - jeder Seitenaufruf ist träge.
Daher wollte ich euch mal fragen, was man da optimieren kann.
Und ob eure Systeme deutlich schneller sind oder ich vielleicht falsche Erwartungen habe.
unser System ist vielleicht vergleichbar.
Wir haben die vierfache Zahl von Artikeln und Tickets, die dreifache Zahl von offenen Tickets, aber Eskalationen deaktiviert.
Es handelt sich bei uns um eine Maschine auf VMware mit SAN.
Die Anhänge liegen in unserer Postgres-DB. Der Cache der DB (und natürlich auch das virtuelle RAM) ist so groß, dass alle Artikel ohne Anhänge reinpassen. Das ist bei uns einer der entscheidenden Punkte.
Wir machen per cron automatische SQL-Abfragen welche für die Verdrängung der Attachments aus dem DB-Cache sorgen sollen.
Andernfalls müssten wir die Attachments auf das FS verlagern.
Im Suchindex haben wir alle Artikel vollständig, es ist also in Wirklichkeit gar kein Index.
Dadurch wird bei der Volltext-Suche viel CPU-Leistung benötigt.
Wir stellen der DB für die Suche deshalb bis zu 16 CPUs zur Verfügung und kommen dann auf maximale Suchzeiten von 6 Sekunden.
Die Suche nach anderen Kriterien (Queue, Status, ...) ist natürlich schneller (2 - 3 Sekunden) und weniger CPU-lastig.
Bei allen genannten Messungen liegen wir um den Faktor 2 - 5 besser.
Unsere Messungen streuen auch deutlich weniger.
Streuungen bei den Messungen (6-22 Sekunden bzw. 8-33 Sekunden) könnten auf eine nicht optimale DB hindeuten.
Was mich wundert ist Eure DB-Größe.
Sie ist mit 1,3 TB mehr als 10 Mal größer als unsere obwohl wir deutlich mehr Artikel und Tickets und sogar die Attachments in der DB haben.
CD
Znuny6/Debian/ESXi
-
- Znuny expert
- Posts: 287
- Joined: 16 Apr 2016, 08:55
- Znuny Version: see in post
- Real Name: Hans
- Contact:
Re: Performanceprobleme?
hi in die Runde
ich betreue hier eine OTRS Instanz mit ca. 40GB DB und ca. 8Mio TIckets.
Der größte Boost war von mysql/maria 5.5 auf maria 10.x zu wechseln
Der nächste Boost war dann den InnoDB Cache auf paar GB anzuheben. In meinem Fall auf 8GB
Und ich musste noch Indices anlegen, die auf Create-Time und Change-Time gingen. Meine Anwender sind angewiesen Suchen mit Create oder Changed durchzuführen.
Die Zugriffszeiten gingen von mehreren Sekunden auf nahezu "sofort" zurück.
1.300GB DB Größe sieht aber danach aus, dass noch nie die DB analysiert & optimiert wurde. Schon mal laufen lassen?
ich betreue hier eine OTRS Instanz mit ca. 40GB DB und ca. 8Mio TIckets.
Der größte Boost war von mysql/maria 5.5 auf maria 10.x zu wechseln
Der nächste Boost war dann den InnoDB Cache auf paar GB anzuheben. In meinem Fall auf 8GB
Und ich musste noch Indices anlegen, die auf Create-Time und Change-Time gingen. Meine Anwender sind angewiesen Suchen mit Create oder Changed durchzuführen.
Die Zugriffszeiten gingen von mehreren Sekunden auf nahezu "sofort" zurück.
1.300GB DB Größe sieht aber danach aus, dass noch nie die DB analysiert & optimiert wurde. Schon mal laufen lassen?
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: Performanceprobleme?
Vielen Dank erstmal für eure ausführlichen Antworten!
Unsere Datenbank wiegt tatsächlich nur 1391,5 MB.
Da wir erst im Nachhinein den ArticleStorage umgelegt haben, ist die DB auf Dateiebene aber leider 18 GB groß - sozusagen mit Luft gefüllt.
Danke für den Tipp mit MariaDB 10.X, da wollte ich eh schon nach Erfahrungen gefragt haben.
Ich habe mir nun einen Klon unseres Ticketsystems erstellt, damit ich dort folgendes in Ruhe testen kann:
- Update auf MariaDB 10
- Aufräumen mit mysqlcheck
- Vergrößerung InnoDB Cache
- Deaktivierung Query Cache (https://mariadb.com/kb/en/mariadb-memor ... uery-cache)
Unsere Datenbank wiegt tatsächlich nur 1391,5 MB.
Da wir erst im Nachhinein den ArticleStorage umgelegt haben, ist die DB auf Dateiebene aber leider 18 GB groß - sozusagen mit Luft gefüllt.
Danke für den Tipp mit MariaDB 10.X, da wollte ich eh schon nach Erfahrungen gefragt haben.
Ich habe mir nun einen Klon unseres Ticketsystems erstellt, damit ich dort folgendes in Ruhe testen kann:
- Update auf MariaDB 10
- Aufräumen mit mysqlcheck
- Vergrößerung InnoDB Cache
- Deaktivierung Query Cache (https://mariadb.com/kb/en/mariadb-memor ... uery-cache)
-
- Znuny expert
- Posts: 287
- Joined: 16 Apr 2016, 08:55
- Znuny Version: see in post
- Real Name: Hans
- Contact:
Re: Performanceprobleme?
bitte hier die Ergebnisse posten, damit auch andere profitieren
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: Performanceprobleme?
Sooo, Rückmeldung besser spät als nie...
Folgendes habe ich Ende August umgesetzt:
Die Performance hat sich gefühlt leider kaum verändert und auch die gemessenen Zugriffszeiten direkt nach der "Performanceoptimierung" waren soweit ich mich richtig entsinne nicht viel besser. Vergleichswerte liefere ich gleich nach.
Folgendes habe ich Ende August umgesetzt:
- vm.swappiness von 30 auf 10 reduziert
- Upgrade auf MariaDB10
- Re-Import der Datenbank (um "die Luft rauszulassen")
- mysqlcheck --analyze
- mysqlcheck --optimize
- mysql server.conf angepasst:
- innodb_file_per_table=ON
- innodb_buffer_pool_size = 1024000000
- query_cache_type = OFF
- query_cache_size = 0
- max_connections = 400
- Ramdisk (tmpfs /opt/otrs/var/tmp) von 1 auf 2 GB erhöht
- RAM von 6 auf 12 GB erhöht
- CPU Kerne von 6 auf 10 erhöht
Die Performance hat sich gefühlt leider kaum verändert und auch die gemessenen Zugriffszeiten direkt nach der "Performanceoptimierung" waren soweit ich mich richtig entsinne nicht viel besser. Vergleichswerte liefere ich gleich nach.
You do not have the required permissions to view the files attached to this post.
Last edited by Charburner on 22 Oct 2021, 18:20, edited 1 time in total.
-
- Znuny newbie
- Posts: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: Performanceprobleme?
Achso, nach dem ganzen Geraffel hatte ich noch die Caches und Indexe neu generiert:
Veränderung der Zugriffszeiten:
Zufrieden bin ich mit dem Ergebnis nicht. Wünschenswert wäre eine Verbesserung um 50% der aktuellen Zeiten. Oder wenigstens eine fühlbare Geschwindigkeitssteigerung beim Suchen und beim Öffnen einzelner Tickets aus Übersichten. Leider weiß ich im Moment nicht, was ich noch versuchen soll bzw. wo etwas hinsichtlich der Konfiguration falsch läuft![Sad :(](./images/smilies/icon_sad.gif)
PS: Hier noch ein aktueller CacheBenchmark:
Code: Select all
perl /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
perl /opt/otrs/bin/otrs.Console.pl Maint::Config::Rebuild
perl /opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup
perl /opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheGenerate
perl /opt/otrs/bin/otrs.Console.pl Maint::Ticket::QueueIndexRebuild
perl /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndexRebuildWorker
perl /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndex --rebuild
perl /opt/otrs/bin/otrs.Console.pl Maint::Ticket::EscalationIndexRebuild
Aufruf der Übersicht: 4-6 Sekunden => keine Änderung
Aufruf eines Tickets aus der Übersicht: 5-7 Sekunden => keine Änderung
Ansicht nach Queues: 16 Sekunden => 10-12 Sekunden
Ansicht nach Status: 10 Sekunden => 8-9 Sekunden
Ansicht nach Eskalationen: 19 Sekunden => 12-18 Sekunden
Verschiedene Suchen mit 150-500 Ergebnissen: 6-22 Sekunden => keine Änderung
Seitenwechsel in den Suchergebnissen: 8-33 Sekunden => keine Änderung
Zufrieden bin ich mit dem Ergebnis nicht. Wünschenswert wäre eine Verbesserung um 50% der aktuellen Zeiten. Oder wenigstens eine fühlbare Geschwindigkeitssteigerung beim Suchen und beim Öffnen einzelner Tickets aus Übersichten. Leider weiß ich im Moment nicht, was ich noch versuchen soll bzw. wo etwas hinsichtlich der Konfiguration falsch läuft
![Sad :(](./images/smilies/icon_sad.gif)
PS: Hier noch ein aktueller CacheBenchmark:
You do not have the required permissions to view the files attached to this post.
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceprobleme?
Hi,
Was für Kundenbenutzer Backends nutzt Du und und welche Cachezeiten sind da konfiguriert?
- Roy
Was für Kundenbenutzer Backends nutzt Du und und welche Cachezeiten sind da konfiguriert?
- 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: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: Performanceprobleme?
Hallo Roy,
es läuft alles in der lokalen Datenbank. Es sind keinerlei externe Backends angebunden.
Gruß
Jens
es läuft alles in der lokalen Datenbank. Es sind keinerlei externe Backends angebunden.
Gruß
Jens
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Performanceprobleme?
Hi,
Sind Eskalationen aktiv und wenn ja wie ist denn so das Duchschnitts der Tickets die eskaliert sind?
- Roy
Sind Eskalationen aktiv und wenn ja wie ist denn so das Duchschnitts der Tickets die eskaliert sind?
- 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: 30
- Joined: 06 Aug 2021, 12:13
- Znuny Version: 6.2.2
- Real Name: Jens
Re: Performanceprobleme?
Die Frage nach den Backends und eskalierten Tickets wurde ja zu Beginn des Threads bereits gestellt.
Seit dem sind es noch mehr eskalierte Tickets geworden. Ich schätze das Durchschnittsalter auf 80-100 Tage.
Aktiviert ist generell nur die Eskalation nach Aktualisierungszeit (4800 Minuten).
Würdet ihr sagen, dass sich die Geschwindigkeit bei Ticket-Übersichten und -suchen spürbar verbessert, wenn der Großteil dieser Tickets geschlossen wird?
Seit dem sind es noch mehr eskalierte Tickets geworden. Ich schätze das Durchschnittsalter auf 80-100 Tage.
Aktiviert ist generell nur die Eskalation nach Aktualisierungszeit (4800 Minuten).
Würdet ihr sagen, dass sich die Geschwindigkeit bei Ticket-Übersichten und -suchen spürbar verbessert, wenn der Großteil dieser Tickets geschlossen wird?
You do not have the required permissions to view the files attached to this post.
-
- Znuny superhero
- Posts: 889
- Joined: 15 Dec 2016, 15:13
- Znuny Version: All
- Real Name: Emin
- Company: Efflux GmbH
- Contact:
Re: Performanceprobleme?
In einigen Masken wahrscheinlich drastisch.
Es würde schon ausreichen, wenn die Service-Zeiten verschwinden würden; die Tickets müssen nicht extra geschlossen werden.
Die scheinen auch eher Empfehlungen zu sein![Razz :P](./images/smilies/icon_razz.gif)
— Emin
Es würde schon ausreichen, wenn die Service-Zeiten verschwinden würden; die Tickets müssen nicht extra geschlossen werden.
Die scheinen auch eher Empfehlungen zu sein
![Razz :P](./images/smilies/icon_razz.gif)
— Emin
Professional OTRS, Znuny & OTOBO services: efflux.de | efflux.de/en/
Free and premium add-ons: German | English
Free and premium add-ons: German | English
Re: Performanceprobleme?
bist Du hier weitergekommen?Charburner wrote: ↑11 Aug 2021, 12:18 Hier mal ein paar Aufrufe, die ich mit der Firefox Netzwerkanalyse gemessen habe:
Aufruf der Übersicht: 4-6 Sekunden
Aufruf eines Tickets aus der Übersicht: 5-7 Sekunden
Ansicht nach Queues: 16 Sekunden
Ansicht nach Status: 10 Sekunden
Ansicht nach Eskalationen: 19 Sekunden
Verschiedene Suchen mit 150-500 Ergebnissen: 6-22 Sekunden
Seitenwechsel in den Suchergebnissen: 8-33 Sekunden
Es handelt sich um Znuny 6.0.34 (vorher OTRS 6 Community), das auf CentOS 7.9 in einer Hyper-V VM mit 6 Kernen und 6 GB RAM läuft.
Das Verzeichnis /opt/otrs/var/tmp wurde in eine 1 GB RAM-Disk (tmpfs) ausgelagert. Den ArticleStorage haben wir vor einiger Zeit von DB auf FS umgestellt.