OTOBO / Znuny - Leistungsverbesserung- Performance Improvement

Dies ist eine Liste von Techniken zur Leistungssteigerung für Ihre OTOBO-Installation. Die Themen umfassen Konfiguration, Programmierung, Speichernutzung und mehr.

Ticketindexmodul

Das Ticketindexmodul kann über die Systemkonfigurationseinstellung Ticket::IndexModule festgelegt werden. Es gibt zwei Backend-Module, die den Index für die Ticketwarteschlangenansicht erstellen:

Kernel::System::Ticket::IndexAccelerator::RuntimeDB

Dies ist die Standardoption, die jede Warteschlangenansicht dynamisch aus der Tickettabelle generiert. Sie werden keine Leistungsprobleme haben, solange Sie etwa 60.000 offene Tickets in Ihrem System haben.

Kernel::System::Ticket::IndexAccelerator::StaticDB

Das leistungsfähigste Modul, das verwendet werden sollte, wenn Sie über 80.000 offene Tickets haben. Es verwendet eine zusätzliche ticket_index-Tabelle, die mit Schlüsselwörtern basierend auf Ticketdaten gefüllt wird. Verwenden Sie den folgenden Befehl, um einen initialen Index zu erstellen, nachdem Sie die Backends gewechselt haben:

otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild

Ticketsuchindex

OTOBO verwendet einen speziellen Suchindex, um Volltextsuchen über Felder in Artikeln aus verschiedenen Kommunikationskanälen durchzuführen.

Um einen initialen Index zu erstellen, verwenden Sie diesen Befehl:

otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild

Notiz

Die tatsächliche Artikelerfassung erfolgt über einen OTOBO-Dämonenjob im Hintergrund. Während Artikel, die gerade zum System hinzugefügt wurden, sofort zur Indizierung markiert werden, kann es vorkommen, dass ihr Index erst nach einigen Minuten verfügbar ist.

Es gibt einige Optionen für die Feinabstimmung des Suchindexes:

Ticket::SearchIndex::IndexArchivedTickets

Definiert, ob archivierte Tickets in den Suchindex einbezogen werden sollen ( standardmäßig deaktiviert). Dies ist ratsam, um den Index in großen Systemen mit archivierten Tickets klein zu halten. Wenn dies aktiviert ist, werden archivierte Tickets bei Volltextsuchen gefunden.

Ticket::SearchIndex::Attribute

Grundlegende Volltextindexeinstellungen.

Images Sysconfig Searchindex Attribute [1]

Notiz

Führen Sie den folgenden Befehl aus, um einen neuen Index zu erstellen:

/opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndexRebuild

• WordCountMax Definiert die maximale Anzahl von Wörtern, die verarbeitet werden, um den Index aufzubauen. Zum Beispiel werden nur die ersten 1000 Wörter eines Artikelkörpers im Artikelsuchindex gespeichert.

• WordLengthMin und WordLengthMax Werden als Wortlängengrenzen verwendet. Nur Wörter mit einer Länge zwischen diesen beiden Werten werden im Artikelsuchindex gespeichert.

Ticket::SearchIndex::Filters

Filter basierend auf regulären Ausdrücken schließen Teile des Originaltexts aus dem Volltextindex aus.

Sysconfig Ticket Search Index Filters [1]

Es sind drei Standardfilter definiert:

• Der erste Filter entfernt Sonderzeichen wie: , & < > ? " ! * | ; [ ] ( ) + $ ^ =

• Der zweite Filter entfernt Wörter, die mit einem der folgenden Zeichen beginnen oder enden: ' : .

• Der dritte Filter entfernt Wörter, die keinen Wortcharakter enthalten: a-z, A-Z, 0-9, _

Ticket::SearchIndex::StopWords

Englische Stoppwörter für den Volltextindex. Diese Wörter werden aus dem Suchindex entfernt.

Sysconfig Searchindex Stopwords[1]

Es sind sogenannte Stoppwörter für einige Sprachen definiert. Diese Stoppwörter werden beim Erstellen des Suchindexes übersprungen.

Tips

Wenn Ihre Sprache nicht in den Systemkonfigurationseinstellungen vorhanden ist oder Sie weitere Wörter hinzufügen möchten, können Sie diese zu dieser Einstellung hinzufügen:

• Ticket::SearchIndex::StopWords###Custom

Dokumentsuche

OTOBO verwendet Elasticsearch für seine Dokumentsuchfunktionalität. Für eine gute Einführung in die Konzepte, Installation und Nutzung von Elasticsearch, folgen Sie bitte dem Getting Started-Handbuch.

Heap-Größe

Elasticsearch ist in Java geschrieben und läuft daher in einer Java-Virtual-Machine (JVM) auf jedem Cluster-Knoten. Eine solche JVM verwendet einen Teil des Speichers, genannt Heap, dessen Größe in der Konfigurationsdatei jvm.options eingestellt werden kann.

Die Heap-Mindest- und Höchstkonfigurationen sind standardmäßig auf einen Wert von 1 GB festgelegt und können mit den folgenden Optionen geändert werden:

• Xms1g: minimale Heap-Größe.

• Xmx1g: maximale Heap-Größe.

Wenn Xms einen niedrigeren Wert als Xmx hat, wird die JVM den genutzten Heap jederzeit vergrößern, wenn das aktuelle Limit überschritten wird, bis der Wert von Xmx erreicht ist. Eine solche Größenanpassung verursacht eine Unterbrechung des Dienstes, bis sie abgeschlossen ist, was die Geschwindigkeit und Reaktionsfähigkeit der Such- oder Indexierungsaktionen verringern kann. Daher wird dringend empfohlen, diese Konfigurationen auf einen gleichen Wert einzustellen.

Warnung

Wenn die maximale Heap-Größe überschritten wird, stoppt der zugehörige Cluster-Knoten die Arbeit und kann sogar den Dienst herunterfahren.

Je höher der maximale Heap-Wert eingestellt ist, desto mehr Speicher kann von Elasticsearch verwendet werden, was auch die möglichen Pausen für die Garbage Collection durch die JVM erhöht. Daher wird empfohlen, einen Wert für Xmx zu setzen, der nicht höher als 50% des physischen Speichers ist.

Für weitere Informationen und gute Faustregeln bezüglich der Heap-Größe folgen Sie bitte der offiziellen Dokumentation.

Speicherzuteilung

Während des Betriebs überprüft Elasticsearch den verfügbaren Speicherplatz. Basierend auf dem Ergebnis entscheidet es, ob neue Shards einem Cluster-Knoten zugewiesen werden. In einigen Fällen verlagert es sogar Shards von einem Knoten weg. Dieses Verhalten wird durch die aktuelle Speicherkapazität bestimmt. Es kann durch Einstellungen in der Konfigurationsdatei elasticsearch.yml konfiguriert werden. Hier sind einige relevante Konfigurationseinstellungen. Sie kommen mit guten Standardwerten, sind aber in der Fehlersuche möglicherweise wichtig.

cluster.routing.allocation.disk.watermark.low

Standardwert von 85%. Wenn dieses Limit überschritten wird, wird Elasticsearch keine weiteren Shards mehr dem zugehörigen Cluster-Knoten zuweisen. Der Betrieb dieses Knotens wird nicht beeinträchtigt, und Daten können weiterhin indiziert und gesucht werden.

cluster.routing.allocation.disk.watermark.high

Standardwert von 90%. Wenn dieses Limit überschritten wird, wird Elasticsearch versuchen, vorhandene Shards auf andere Knoten zu verlagern, die genügend Speicherplatz zur Verfügung haben.

cluster.routing.allocation.disk.watermark.flood_stage

Standardwert von 95%. Wenn dieses Limit überschritten wird, wird Elasticsearch die Konfiguration aller Indizes, die mindestens einen Shard auf dem zugehörigen Cluster-Knoten zugewiesen haben, auf schreibgeschützte Indexblöcke aktualisieren. Speziell werden sie mit index.blocks.read_only_allow_delete markiert. Nach diesem Update ist es nicht mehr möglich, neue Daten zu solchen Indizes zu indizieren. Die Indizes sind eingeschränkt auf Suchen und Löschaktionen.

Notiz

Wenn die Flutschwelle überschritten wurde und bestimmte Indizes auf den schreibgeschützten Modus eingestellt sind, wird eine solche Konfiguration nicht automatisch von Elasticsearch geändert. Wenn die zugehörigen Festplatten aufgrund manueller Aktionen wieder genügend freien Speicherplatz enthalten, muss die Konfiguration manuell wieder in den Normalmodus geändert werden.

Für weitere Informationen über Festplatten-Wasserzeichen und festplattenbasierte Shard-Zuweisung folgen Sie bitte der offiziellen Dokumentation.

Artikel Speicherung

Es gibt zwei verschiedene Backend-Module für die Artikelspeicherung von Telefon-, E-Mail- und internen Artikeln. Der verwendete Artikelspeicher kann in der Einstellung Ticket::Article::Backend::MIMEBase::ArticleStorage konfiguriert werden.

Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB

Dieses Standardmodul speichert Anhänge in der Datenbank. Es funktioniert auch mit mehreren Frontend-Servern, benötigt jedoch viel Speicherplatz in der Datenbank.

Notiz

Verwenden Sie dies nicht bei großen Setups.

Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFS

Verwenden Sie dieses Modul, um Anhänge auf dem lokalen Dateisystem zu speichern. Es ist schnell, aber wenn Sie mehrere Frontend-Server haben, müssen Sie sicherstellen, dass das Dateisystem zwischen den Servern geteilt wird. Platzieren Sie es auf einem NFS-Share oder vorzugsweise einem SAN oder einer ähnlichen Lösung.

Notiz

Empfohlen für große Setups.

Sie können jederzeit zwischen einem Backend und dem anderen wechseln. Sie können das Backend in der Systemkonfiguration wechseln und dann dieses Befehlszeilentool ausführen, um die Artikel aus der Datenbank auf das Dateisystem zu verschieben oder umgekehrt:

otobo> /opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

Sie können die Option --target verwenden, um das Ziel-Backend anzugeben.

Notiz

Der gesamte Prozess kann je nach Anzahl der Artikel, die Sie haben, und der verfügbaren CPU-Leistung und/oder Netzwerkkapazität erhebliche Zeit in Anspruch nehmen.

Wenn Sie alte Anhänge in der Datenbank behalten möchten, können Sie die Systemkonfigurationsoption Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends aktivieren, um sicherzustellen, dass OTOBO sie dennoch findet.

Tickets Archivieren

Da OTOBO als prüffähiges System verwendet werden kann, ist das Löschen geschlossener Tickets möglicherweise keine gute Idee. Daher gibt es eine Funktion, die es Ihnen erlaubt, Tickets zu archivieren.

Tickets, die bestimmte Kriterien erfüllen, können als archiviert markiert werden. Diese Tickets werden nicht abgerufen, wenn Sie eine reguläre Ticketsuche durchführen oder einen generischen Agentenjob ausführen. Das System selbst muss nicht mehr mit einer riesigen Anzahl von Tickets umgehen, da nur die neuesten Tickets bei der Verwendung von OTOBO berücksichtigt werden. Dies kann auf großen Systemen zu einem enormen Leistungsgewinn führen.

Um die Archivfunktion zu nutzen:

1. Aktivieren Sie die Einstellung Ticket::ArchiveSystem in der Systemkonfiguration.

2. Definieren Sie einen generischen Agentenjob:

   • Klicken Sie auf die Schaltfläche Job hinzufügen im Bildschirm Generischer Agent.

   • Jobeinstellungen: Geben Sie einen Namen für den Archivierungsjob an.

   • Automatische Ausführung: Wählen Sie geeignete Optionen, um diesen Job zu planen.

   • Tickets auswählen: Es könnte eine gute Idee sein, nur solche Tickets im geschlossenen Status zu archivieren, die einige Monate zuvor geschlossen wurden.

   • Ticketattribute aktualisieren/hinzufügen: Setzen Sie das Feld Ausgewählte Tickets archivieren auf Tickets archivieren.

   • Speichern Sie den Job am Ende der Seite.

   • Klicken Sie auf den Link Diese Aufgabe ausführen in der Übersichtstabelle, um die betroffenen Tickets zu sehen.

   • Klicken Sie auf die Schaltfläche Job ausführen.

Notiz

Bis zu 5000 Tickets können durch manuelles Ausführen dieses Jobs geändert werden.

Wenn Sie nach Tickets suchen, suchen die Systemstandardwerte nach Tickets, die nicht archiviert sind.

Um nach archivierten Tickets zu suchen:

1. Öffnen Sie den Ticket-Suchbildschirm.

2. Setzen Sie die Archivsuche auf Nicht archivierte Tickets oder Alle Tickets.

3. Führen Sie die Suche durch.

Caching

Ein schnelles Cache-Modul ist eine große Hilfe in Bezug auf die Leistung. Wir empfehlen die Verwendung eines Redis Cache-Servers oder das Erstellen eines Ramdisks.

Installieren Sie einen Redis Cache-Server

1. Installieren Sie den Redis Server

Zuerst müssen Sie den neuesten Redis Server installieren. Der einfachste Weg ist, Redis einzurichten auf dem gleichen Host wie OTOBO und es an dessen Standardport zu binden.

2. Installieren Sie das Perl-Modul Redis oder Redis::Fast

Sie können wählen, welches Redis-Modul Sie verwenden möchten: Redis]{.title-ref} oder [Redis::Fast ( welches kompatibel mit Redis ist, aber ~2x schneller). Bitte verwenden Sie otobo.CheckModules.pl --list, um das richtige Paket für Sie zu wählen:

3. Konfigurieren Sie OTOBO für Redis

Verwenden Sie bitte das OTOBO SysConfig (Admin -> Systemkonfiguration), um OTOBO richtig zu konfigurieren:

| Einstellung                   | Beschreibung                   | Standardwert   |

| ----------------------------- | ------------------------------ | -------------- |

| Cache::Redis###Server         | Redis-Server-URL               | 127.0.0.1:6379 |

| Cache::Redis###DatabaseNumber | Anzahl logischer Datenbanken   | 0              |

| Cache::Redis###RedisFast      | Verwendung von Redis::Fast     | 0              |

| Cache::Module                 | Aktivieren des Redis-Cache-Moduls | DB (verwende Redis) |

RamDisk-Caching

OTOBO speichert viele temporäre Daten in /opt/otobo/var/tmp. Bitte stellen Sie sicher, dass dies ein leistungsstarkes Dateisystem und Speichermedium verwendet. Wenn Sie genug RAM haben, können Sie auch versuchen, dieses Verzeichnis auf einem Ramdisk zu speichern, wie folgt:

otobo> /opt/otobo/bin/otobo.Console.pl Maint::Session::DeleteAll

otobo> /opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete

root> mount -o size=16G -t tmpfs none /opt/otobo/var/tmp

Notiz

Fügen Sie einen persistenten Einhängpunkt in /etc/fstab hinzu.

Warnung

Dies wird ein nicht dauerhafter Speicher sein, der bei einem Serverneustart verloren geht. Alle Ihre Sitzungen (wenn Sie sie im Dateisystem speichern) und Ihre Cache-Daten gehen verloren.

FAQs

Wie kann das Ticketindexmodul zur Leistungssteigerung konfiguriert werden?

Das Ticketindexmodul kann über die Systemkonfigurationseinstellung Ticket::IndexModule festgelegt werden.

Wie kann ein neuer Index für die Ticketsuche erstellt werden?

Um einen neuen Index für die Ticketsuche zu erstellen, kann der Befehl /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndexRebuild verwendet werden.

Wie erfolgt die Dokumentsuche in OTOBO?

OTOBO verwendet Elasticsearch für die Dokumentsuchfunktionalität.

Wie kann die Artikelspeicherung in OTOBO konfiguriert werden?

Die Artikelspeicherung von Telefon-, E-Mail- und internen Artikeln kann durch die Einstellung Ticket::Article::Backend::MIMEBase::ArticleStorage konfiguriert werden.

Wie wird die Archivierung von Tickets in OTOBO umgesetzt?

Tickets, die bestimmte Kriterien erfüllen, können als archiviert markiert werden. Diese Funktion ermöglicht es, Tickets zu archivieren, um die Leistung zu verbessern.

OTOBO Dienstleistungen

Wir bieten verschiedene Dienstleistungen rund um OTOBO an. Dazu gehören:

• OTOBO Beratung
• OTOBO Installation
• OTOBO Anpassungen
• OTOBO Schulungen
• OTOBO Support

Wenn du Interesse an unseren Dienstleistungen hast, dann schreib uns eine E-Mail an

tab@softoft.de

Oder erfahre mehr über unsere OTOBO Dienstleistungen