Veraltete Dokumentation

Sie sehen sich die Dokumentation zu einem älteren Release an. Die neuesten Informationen finden Sie in der Dokumentation der aktuellen Version.

Leistungsverbesserung

Es gibt eine Liste mit leistungsverbessernden Techniken für Ihre OTRS-Installation, einschließlich Konfiguration, Codierung, Speichernutzung und mehr.

Ticket-Indexmodul

Das Ticket-Index-Modul kann in der Systemkonfigurationseinstellung Ticket::IndexModule eingestellt werden. Es gibt zwei Backend-Module für den Index der Ticket-Queueansicht:

Kernel::System::Ticket::IndexAccelerator::RuntimeDB
Das ist die Standardoption und generiert jede Queueansicht direkt aus der Ticket-Tabelle. Bei bis zu ca. 60.000 in Ihrem System offenen Tickets werden Sie damit keine Leistungsprobleme haben.
Kernel::System::Ticket::IndexAccelerator::StaticDB

Das leistungsstärkste Modul sollte verwendet werden, wenn Sie über 80.000 offene Tickets haben. Es verwendet eine zusätzliche ticket_index-Tabelle, die mit auf Ticketdaten basierenden Schlüsselwörtern aufgefüllt wird. Verwenden Sie den folgenden Befehl, um einen Anfangsindex nach dem Wechsel der Backends zu erstellen:

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

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

Bemerkung

Die eigentliche Artikelindizierung erfolgt über einen OTRS-Daemon-Job im Hintergrund. Weil die Artikel, die gerade dem System hinzugefügt wurden, sofort für die Indizierung markiert werden, kann es sein, dass ihr Index erst innerhalb einiger Minuten verfügbar ist.

Es gibt einige Optionen zur Feinabstimmung des Suchindex:

Ticket::SearchIndex::Attribute

Grundlegende Einstellungen für den Volltextindex.

``Ticket::SearchIndex::Attribute`` Setting

Ticket::SearchIndex::Attribute Einstellung

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.

``Ticket::SearchIndex::Filters`` Setting

Ticket::SearchIndex::Filters Einstellung

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.

``Ticket::SearchIndex::StopWords###en`` Setting

Ticket::SearchIndex::StopWords###en Einstellung

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

Artikelspeicherung

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

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.

Bemerkung

Der gesamte Prozess kann einige Zeit in Anspruch nehmen, abhängig von der Anzahl der Artikel, der verfügbaren CPU-Leistung und / oder der Netzwerkkapazität.

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 OTRS diese weiterhin findet.

Tickets archivieren

Da OTRS als revisionssicheres System betrieben werden kann, ist das Löschen von geschlossenen Tickets möglicherweise nicht empfehlenswert. Daher haben wir eine Funktion implementiert, mit der Sie Tickets archivieren können.

Tickets, die bestimmten Kriterien entsprechen, können als archiviert markiert werden. Auf diese Tickets wird nicht zugegriffen, wenn Sie eine reguläre Ticketsuche durchführen oder einen generischen Agentenjob ausführen. Das System selbst muss nicht mehr mit einer großen Anzahl von Tickets umgehen, da bei der Verwendung von OTRS nur die neuesten Tickets berücksichtigt werden. Dies kann bei großen Systemen zu einem enormen Leistungszuwachs führen.

So verwenden Sie die Archivfunktion:

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

  2. Definieren Sie einen GenericAgent-Job:

    • Klicken Sie im Bildschirm GenericAgent auf die Schaltfläche Job hinzufügen.
    • Job-Einstellungen: Geben Sie einen Namen für den Archivierungsjob an.
    • Automatische Ausführung: Wählen Sie die richtigen Optionen aus, um diesen Job zu planen.
    • Tickets selektieren: Es kann eine gute Idee sein, nur die Tickets in einem geschlossenen Zustand 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 in der Übersichtstabelle auf den Link Diese Aufgabe ausführen , um die betroffenen Tickets anzuzeigen.
    • Klicken Sie auf die Schaltfläche Diesen Job ausführen.

    Bemerkung

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

Bei der Suche nach Tickets werden standardmäßig nicht archivierte Tickets durchsucht.

So suchen Sie nach archivierten Tickets:

  1. Öffnen Sie die Ticketsuche.
  2. Setzen Sie Archivsuche auf Nicht archivierte Tickets oder Alle Tickets.
  3. Führen Sie die Suche durch.

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

Bemerkung

Fügen Sie einen dauerhaften Einhängepunkt in /etc/fstab hinzu.

Warnung

Dies ist ein nicht permanenter Speicher, der bei einem Neustart des Servers verloren geht. Alle Ihre Sitzungen (wenn Sie sie im Dateisystem speichern) und Ihre Cache-Daten gehen verloren.

Clustering

For very high loads, it can be required to operate OTRS on a cluster of multiple front end servers. This is a complex task with many pitfalls. Therefore, OTRS Group provides support for clusters in its managed OTRS environment exclusively.

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