Leistungsverbesserung

Ticket-Suchindex

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

Verwenden Sie diesen Befehl, um einen Anfangsindex zu erstellen:

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

Es gibt einige Optionen zur Feinabstimmung des Suchindex:

Ticket::SearchIndex::Attribute

Grundlegende Einstellungen für den Volltextindex.

Bemerkung

Führen Sie das folgende Kommando aus, um einen neuen Index zu generieren:

otrs> /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndexRebuild

WordCountMax

Definiert die maximale Anzahl von Wörtern, die zum Aufbau des Index verarbeitet werden. Zum Beispiel, dass nur die ersten 1000 Wörter des Artikelkörpers im Artikelsuchindex gespeichert werden.

WordLengthMin und WordLengthMax

Wird als Wortlängenbegrenzung verwendet. Nur Wörter mit einer Länge zwischen diesen beiden Werten werden im Artikelsuchindex gespeichert.

Ticket::SearchIndex::Filters

Reguläre Ausdrücke für den Volltextindex-Filter, um Teile des Textes zu entfernen.

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 kein Wortzeichen 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.

Für einige Sprachen sind sogenannte Stoppwörter definiert. Diese Stoppwörter werden beim Erstellen des Suchindex übersprungen.

Siehe auch

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

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

Dokumentensuche

OTRS nutzt Elasticsearch für seine Dokumentensuche. Für eine gute Einführung in die Konzepte, Installation und Nutzung von Elasticsearch lesen Sie bitte das Kapitel Quick start in der offiziellen Dokumentation.

Artikelspeicherung

Es gibt drei 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 Anlagen in der Datenbank. Es funktioniert auch mit mehreren Frontend-Servern, erfordert jedoch viel Speicherplatz in der Datenbank.

Bemerkung

Verwenden Sie dies nicht bei großen Setups.

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

Verwenden Sie dieses Modul, um Anlagen im lokalen Dateisystem zu speichern. Dies ist zwar schnell, aber wenn Sie über mehrere Frontend-Server verfügen, müssen Sie sicherstellen, dass das Dateisystem von den Servern gemeinsam genutzt wird. Legen Sie es auf eine NFS-Freigabe oder vorzugsweise auf ein SAN oder eine ähnliche Lösung.

Bemerkung

Empfohlen für große Setups.

Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageAmazonS3

Verwenden Sie dieses Modul, um Anhänge in einem beliebigen AWS S3 kompatiblen Objektspeicher zu speichern.

Es gibt eine Standardverbindung zum AWS S3-Dateispeicher in Kernel/Config/Defaults.pm. Um die Verbindung für Ihre Umgebung zu aktivieren, müssen Sie den folgenden Codesausschnitt zu Kernel/Config.pm hinzufügen:

$Self->{'Ticket::Article::Backend::MIMEBase::ArticleStorage'} = 'Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageAmazonS3';

$Self->{'Ticket::Article::Backend::MIMEBase::ArticleStorageAmazonS3'} = {
    'Active'            => 1,
    'Endpoint'          => 'http://127.0.0.1:9000',
    'Region'            => 'local',
    'AwsAccessKey'      => 'minioadmin',
    'AwsSecretKey'      => 'minioadmin',
    'Bucket'            => 'storage',
    'TestBucket'        => 'unit-test',
    'HealthCheck'       => '/minio/health/live',
    'MaxObjectSize'     => 1024 * 1024 * 20,
    'Reconnect'         => 2,
    'BackoffOnFailure'  => 1,
    'BackoffRetryCount' => 150,
};

Sie können zügig von einem Backend zum anderen wechseln. Sie können das Backend in der Systemkonfiguration wechseln und dann dieses Befehlszeilendienstprogramm ausführen, um die Artikel aus der Datenbank in das Dateisystem zu laden oder umgekehrt:

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

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

Um sicherzustellen, dass Sie während des Migrationsprozesses Zugriff auf alle Artikel haben, können Sie die Systemkonfigurationseinstellung Ticket::Article::Backend::MIMEBase::ArticleStorageBackendCheckOrder verwenden. Diese Einstellung spezifiziert zusätzliche Artikelablage-Backends, die für Artikel und deren Anhänge geprüft werden sollen. Es wird empfohlen, hier das alte Artikelspeicher-Backend hinzuzufügen.

Webserver optimieren

Der integrierte Webserver von OTRS kann kleine und mittlere Setups sofort ausführen. Wenn OTRS von vielen Benutzer gleichzeitig genutzt wird, kann es erforderlich sein, die Webserverkonfiguration zu optimieren, um beispielsweise die Anzahl der Arbeitsprozesse zu erhöhen.

Die Konfigurationsdatei des Webservers befindet sich in Kernel/WebApp.conf, und alle Einstellungen sind dokumentiert. Die Einstellung für Worker kann erhöht werden, um mehr Prozesse für die Bereitstellung von HTTP-Anforderungen auf fähigen Servern bereitzustellen.

Caching

OTRS speichert viele temporäre Daten in /opt/otrs/var/tmp. Stellen Sie sicher, dass dieses Verzeichnis ein Hochleistungs-Dateisystem und -speicher verwendet. Wenn Sie über genügend RAM verfügen, können Sie auch versuchen, dieses Verzeichnis auf einer RAM-Disk wie folgt abzulegen:

otrs> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
root> mount -o size=16G -t tmpfs none /opt/otrs/var/tmp

Clustering

Bei sehr hohen Lasten kann es erforderlich sein, OTRS in einem Cluster mehrerer Frontend-Server zu betreiben. Dies ist eine komplexe Aufgabe mit vielen Fallstricken. Daher bietet die OTRS Group ausschließlich Unterstützung für Cluster in ihrer managed OTRS-Umgebung.

Grenzen von Objekten

Es gibt keine technische Beschränkung, wie viele Objekte im System verwendet werden können, aber die Verwendung einer großen Anzahl von Objekten kann die Systemleistung beeinträchtigen. Die vorgeschlagenen Grenzen gelten nur für Objekte, die als gültig eingestuft sind. Die Objekte, die als ungültig oder vorübergehend ungültig eingestuft sind, werden vom System nicht verwendet.

Um das System schnell und reaktionsschnell zu halten, sollten die folgenden Grenzen für gültige Objekte nicht überschritten werden:

• E-Mail-Konten: 10

• Postmaster-Filter: 50

• ACLs: 80

• Dynamische Felder: 300

• Dynamische Feld-Dropdown- oder Multiselect-Werte pro Feld: 100

• Services: 500

• SLAs: 50

• Queues: 200

• Configuration Item-Klassen: 20

• Configuration Item-Objekte: 20.000

• Prozesse: 50

• Generic Agents:30 (Häufigkeit max. einmal pro Stunde pro Generic Agent)

• Ticket-Status: 20

• Ticket-Typen: 10

• Terminkalender: 50

• Artikel pro Ticket: 500