Performance Tuning¶
Hier finden Sie eine Reihe von Möglichkeiten, die Leistung Ihrer OTOBO-Installation zu verbessern – z. B. durch Konfiguration, Entwicklung, Speichernutzung, etc.
Ticket-Indexmodul¶
Das Ticket-Indexmodul kann in der Systemkonfiguration über die Einstellung Ticket::IndexModule
konfiguriert werden. Zwei Backend-Module bilden den Index für die Ticket-Ansicht nach Queues:
Kernel::System::Ticket::IndexAccelerator::RuntimeDB
- Die Standardoption, in der jede Queue-Ansicht zur Laufzeit aus der Tickettabelle generiert wird. Keine Performance-Beeinträchtigungen zu erwarten bis etwa 60.000 offene Tickets im System sind.
Kernel::System::Ticket::IndexAccelerator::StaticDB
Das leistungsstärkste Modul. Empfohlen bei über 80.000 offenen Tickets im System. Das Modul verwendet eine spezielle
ticket_index
-Tabelle, die auf Basis der Ticketdaten mit Keywords bestückt wird. Verwenden Sie folgenden Befehl, um nach der Umstellung auf ein anderes Backend einen ersten Index zu generieren:otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild
Ticket-Suchindex¶
OTOBO nutzt einen speziellen Suchindex, um felderübergreifende Volltextsuchen in Artikeln aus unterschiedlichen Kommunikationskanälen durchzuführen.
Verwenden Sie folgenden Befehl, um einen initialen Index zu erstellen:
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild
Bemerkung
Die eigentliche Artikelindexierung erfolgt über einen OTOBO Daemon-Job im Hintergrund. Auch wenn neu hinzugefügte Artikel sofort zur Indexierung markiert werden, kann es deshalb sein, dass ihr Index erst nach einigen Minuten zur Verfügung steht.
Es gibt einige Möglichkeiten, den Suchindex granularer abzustimmen:
Ticket::SearchIndex::IndexArchivedTickets
- Definiert, ob archivierte Tickets in den Suchindex aufgenommen werden (standardmäßig deaktiviert). Empfehlenswert, um den Suchindex in großen Systemen mit vielen archivierten Tickets klein zu halten. Ist die Option aktiviert, werden auch archivierte Tickets über die Volltextsuche gefunden.
Ticket::SearchIndex::Attribute
Grundlegende Einstellungen für die Volltextsuche.
Bemerkung
Führen Sie folgenden Befehl aus, um einen neuen Index zu generieren:
otobo> /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndexRebuild
WordCountMax
- Definiert die maximale Anzahl beim Indexaufbau berücksichtigter Worte. Beispiel: Im Artikel-Suchindex werden nur die ersten 1.000 Wörter des Artikel-Body gespeichert.
WordLengthMin
undWordLengthMax
- Werden zur Begrenzung der Wortlänge verwendet. Im Artikel-Sucheindex werden nur Wörter mit einer Länge zwischen diesen beiden Werten gespeichert.
Ticket::SearchIndex::Filters
Filter auf Basis regulärer Ausdrücke schließen Teile des Originaltextes aus dem Volltextindex aus.
Standardmäßig sind drei Filter definiert:
- Der erste Filter sortiert Sonderzeichen aus. Zum Beispiel: , & < > ? “ ! * | ; [ ] ( ) + $ ^ =
- Der zweite Filter sortiert Wörter aus, die mit einem der folgenden Zeichen beginnen oder enden: ‚ : .
- Der dritte Filter sortiert Wörter aus, die keines der folgenden Zeichen enthalten: a-z, A-Z, 0-9, _
Ticket::SearchIndex::StopWords
Englische Stopwörter für den Volltext-Index. Diese Wörter werden aus dem Suchindex entfernt.
Für einige Sprachen sind sogenannte Stopwort-Listen definiert. Diese Worte werden beim Anlegen des Suchindex ausgelassen.
Siehe auch
Möchten Sie zusätzliche Wörter ergänzen, können Sie diese unter der folgenden Einstellung hinzufügen:
Ticket::SearchIndex::StopWords###Custom
Dokumentensuche¶
OTOBO nutzt Elasticsearch für die Dokumentensuche. Eine gute Einführung in die Konzeption, Installation und Nutzung von Elasticsearch bietet der Elasticsearch Getting Started Guide.
Heap-Größe¶
Elasticsearch ist in Java geschrieben und läuft folglich in einer Java Virtual Machine (JVM) auf jedem Clusterknoten. Eine solche JVM nutzt einen Teil des Speichers, den sogenannten Heap. Seine Größe kann in der Konfigurationsdatei jvm.options
definiert werden.
Mindest- und Maximalkonfiguration für den Heap sind standardmäßig auf einen Wert von 1 GB fesgelegt und können wie folgt angepasst werden:
Xms1g
: minimale Heapgröße.Xmx1g
: maximale Heapgröße.
Liegt der Xms
-Wert unter dem für Xmx
, passt die JVM den verwendeten Heap bei jeder Überschreitung des aktuellen Limits automatisch an, bis der Xmx
-Wert erreicht ist. Bei jeder Anpassung wird der Dienst bis zum Ende pausiert, so dass Schnelligkeit und Reaktivität der Suche und Indexierung beeinträchtig werden können. Wir empfehlen deshalb dringend, beide Parameter auf den gleichen Wert zu setzen.
Warnung
Wird die maximale Heapgröße überschritten, stoppt der zugehörige Clusterknoten die Arbeit und kann den Dienst sogar herunterfahren.
Je höher die maximale Heapgröße, desto mehr Speicher kann Elasticsearch nutzen. Damit steigt auch die Anzahl möglicher Pausen durch die Garbage Collection der JVM. Es wird deshalb empfohlen, den Wert für ``Xmx``auf maximal 50 % des physischen Speichers zu setzen.
Weitere Informationen und gute Richtwerte für die Heapgröße entnehmen Sie bitte der offiziellen Elasticsearch-Dokumentation.
Festplattennutzung¶
Elasticsearch prüft während der Laufzeit den verfügbaren Festplattenplatz. Je nach Auslastung werden Clusterknoten weitere Shards zugewiesen oder sogar abgezogen. Dieses Verhalten wird durch die verfügbare Festplattenkapazität gesteuert und kann in der Konfigurationsdatei elasticsearch.yml konfiguriert werden. Hier finden Sie einige wichtige Konfigurationen, für die gute Standardwerte vorgegeben sind, die aber von Bedeutung sein können.
cluster.routing.allocation.disk.watermark.low
- Standardwert 85 %. Wird diese Grenze überschritten, weist Elasticsearch dem jeweiligen Clusterknoten keine weiteren Shards zu. Der Betrieb des jeweiligen Knotens wird nicht beeinträchtigt, Daten können weiterhin indexiert und durchsucht werden.
cluster.routing.allocation.disk.watermark.high
- Standardwert 90 % . Wird dieser Grenzwert überschritten, versucht Elasticsearch vorhandene Shards auf andere Knoten mit ausreichend Platz zu verschieben.
cluster.routing.allocation.disk.watermark.flood_stage
- Standardwert 95 %. Wird dieser Grenzwert überschritten, aktualisiert Elasticsearch die Konfiguration aller Indizes, von denen mindestens ein Shard dem jeweiligen Clusterknoten zugeordnet ist, auf schreibgeschützte Indexblöcke. Diese werden mit dem Tag
index.blocks.read_only_allow_delete
gekennzeichnet.Ab diesem Zeitpunkt ist es nicht mehr möglich, neue Daten zum jeweiligen Index hinzuzufügen. Es können nur noch Such- und Löschvorgänge durchgeführt werden.
Bemerkung
Wurde der Grenzwert überschritten und sind bestimmte Indizes auf Readonly gesetzt, wird Elasticsearch diese Konfiguration nicht automatisch wieder zurücksetzen. Haben Sie also von Hand dafür gesorgt, dass wieder genügend Festplattenspeicher verfügbar ist, müssen Sie die Konfiguration von Hand wieder auf Normalmodus zurücksetzen.
Weitere Informationen Hochwassermarken und der Zuweisung von Festplatten-Shards finden Sie in der offiziellen Elasticsearch-Dokumentation.
Artikelspeicher¶
Es gibt zwei verschiedene Backendmodule für die Speicherung von Telefon-, E-Mail- und internen Artikeln. Der verwendete Artikelspeicher kann in der Systemkonfiguration unter Ticket::Article::Backend::MIMEBase::ArticleStorage
definiert werden.
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB
Dieses Standardmodul speichert Anhänge in der Datenbank. Es unterstützt auch mehrere Frontend-Server, benötigt jedoch erheblichen Speicherplatz in der Datenbank.
Bemerkung
Verwenden Sie dieses Modul nicht für große Systeme.
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFS
Verwenden Sie dieses Modul, um Anhänge im lokalen Dateisystem zu speichern. Das Modul ist schnell. Achten Sie aber in Umgebungen mit mehreren Frontendservern darauf, dass die Server das Dateisystem gemeinsam nutzen. Verwenden Sie eine NFS-Freigabe oder eine ähnliche Lösung.
Bemerkung
Empfohlen für große Systeme.
Sie können direkt von einem Backed zum anderen wechseln. Sie können das Backend in der Systemkonfiguration ändern und dann dieses Kommandozeilentool ausführen, um Artikel aus der Datenbank in ein Dateisystem zu verlagern - und andersherum:
otobo> /opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS
Verwenden Sie die Option --target
, um das Ziel-Backend festzulegen.
Bemerkung
Der gesamte Prozess kann je nach Anzahl der vorhandenen Artikel sowie verfügbarer CPU-Leistung und Netzwerkkapazität erhebliche Zeit in Anspruch nehmen.
Wenn Sie alte Anhänge in der Datenbank behalten möchten, können Sie die Option Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends
in der Systemkonfiguration aktivieren, um sicherzustellen, dass OTOBO diese auch weiterhin findet.
Tickets archivieren¶
Da OTOBO als revisionssicheres System betrieben werden kann, ist das Löschen geschlossener Tickets möglicherweise nicht empfehlenswert. Es gibt deshalb eine Funktionalität zum Archivieren von Tickets.
Tickets, die bestimmten Kriterien entsprechen, können als archiviert markiert werden. Archivierte Tickets bleiben bei der regulären Ticketsuche und beim Ausführen von Generic Agent-Jobs außen vor. So muss das System nicht bei jeder Anfrage enorme Ticketmengen verarbeiten, stattdessen werden im Regelfall nur die neuesten - relevanten - Tickets berücksichtigt. Insbesondere bei großen Systemen kann dies eine erhebliche Leistungssteigerung verursachen.
So verwenden Sie die Archivierungsfunktion:
Aktivieren Sie die Einstellung
Ticket::ArchiveSystem
in der Systemkonfiguration.Definieren Sie einen GenericAgent-Job:
- Klicken Sie in der Maske GenericAgent auf die Schaltfläche Job hinzufügen.
- Job-Einstellungen: Geben Sie einen Namen für den Archivierungsauftrag an.
- Automatische Ausführung: Wählen Sie geeignete Parameter zur Planung des Jobs aus.
- Tickets selektieren: Es kann empfehlenswert sein, Tickets erst einige Monate nach dem Schließen zu archivieren.
- Ticketattribute aktualisieren / hinzufügen: Setzen Sie das Feld Ausgewählte Tickets archivieren auf Tickets archivieren.
- Speichern Sie Ihre Einstellungen am Ende der Seite.
- Klicken Sie in der Übersichtstabelle auf Diese Aufgabe ausführen, um alle betroffenen Tickets anzuzeigen.
- Klicken Sie auf die Schaltfläche Diesen Job ausführen.
Bemerkung
Durch manuelles Ausführen dieses Jobs können bis zu 5.000 Tickets geändert werden.
In der Ticketsuche werden archivierte Tickets standardmäßig nicht berücksichtigt.
So suchen Sie nach archivierten Tickets:
- Öffnen Sie die Ticketsuche.
- Setzen Sie Archivsuche auf Nicht archivierte Tickets oder Alle Tickets.
- Führen Sie die Suche aus.
Caching¶
Ein schnelles Cache-Modul verbessert die Systemleistung erheblich. Wir empfehlen die Verwendung eines Redis Cache Servers oder die Erstellung einer RAM-Disk.
Redis Cache Server installieren¶
- Redis Server installieren
Installieren Sie zunächst die neueste Version von Redis Server. Am einfachsten ist es, Redis auf dem gleichen Host wie OTOBO aufzusetzen und an den Standardport zu binden.
- Redis Perl Modul oder Redis::Fast installieren
Es liegt bei Ihnen, welches Redis-Modul Sie nutzen: Redis oder Redis::Fast (das mit Redis vergleichbar aber ~2x schneller ist). Die Ausgabe des Befehls otobo.CheckModules.pl --list
unterstützt Sie bei der Wahl des passenden Paketes für Ihre Installation:
otobo> /opt/otobo/bin/otobo.CheckModules.pl --all
- OTOBO für Redis konfigurieren
Bitte verwenden Sie die OTOBO SysConfig (Administration -> Systemkonfiguration), um OTOBO entsprechend zu konfigurieren:
| Setting | Description | Default value |
| ----------------------------- | -------------------------- | -------------- |
| Cache::Redis###Server | Redis server URL | 127.0.0.1:6379 |
| Cache::Redis###DatabaseNumber | Number of logical database | 0 |
| Cache::Redis###RedisFast | Use or not Redis::Fast | 0 |
| Cache::Module | Activate Redis Cache Module| DB (use Redis) |
RAM-Disk-Caching¶
OTOBO speichert viele temporäre Daten in /opt/otobo/var/tmp
. Stellen Sie sicher, dass für dieses Verzeichnis ein Hochleistungsdateisystem und -speicher eingesetzt wird. Wenn Sie über genügend RAM verfügen, können Sie auch versuchen, dieses Verzeichnis wie folgt auf einer RAM-Disk abzulegen:
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
Warnung
Dies ist ein nicht permanenter Speicher, der bei einem Server-Neustart verloren geht. All Ihre Sitzungen (sofern im Dateisystem gespeichert) und Ihr Cache sind dann verloren.
Cluster¶
Bei sehr hohen Lasten kann es erforderlich sein, OTOBO auf einem Cluster aus mehreren Frontendservern zu betreiben. Dieses Szenario ist komplex und birgt viele Fallstricke. Wir empfehlen dringend, sich mit unseren Experten in Verbindung zu setzen, bevor Sie ein solches Projekt alleine umsetzen.