Inhaltsverzeichnis
Zusammenfassung
Presented below is a list of performance enhancing techniques for your OTRS installation, including configuration, coding, memory use, and more.
Es gibt verschiedene Ansätze zur Leistungssteigerung von OTRS.
There are two backend modules for the index for the ticket queue view:
Kernel::System::Ticket::IndexAccelerator::RuntimeDBThis is the default option, and will generate each queue view on the fly from the ticket table. You will not have performance trouble until you have about 60,000 open tickets in your system.
Kernel::System::Ticket::IndexAccelerator::StaticDB
The most powerful module, should be used when you have above 80,000 open
tickets. It uses an extra ticket_index table, which will
be populated with keywords based on ticket data. Use
bin/otrs.Console.pl Maint::Ticket::QueueIndexRebuild
for generating an initial index after switching backends.
You can change the used IndexAccelerator module via SysConfig.
OTRS uses a special search index to perform full-text searches across fields in articles from different communication channels.
To create an initial index, use bin/otrs.Console.pl
Maint::Ticket::FulltextIndex --rebuild.
Actual article indexing happens via an OTRS daemon job in the background. While articles which were just added in the system are marked for indexing immediately, it could happen their index is available within a few minutes.
There are some options available for fine tuning the search index:
Ticket::SearchIndex::IndexArchivedTicketsDefines if archived tickets will be included in the search index (off by default). This is advisable to keep the index small on large systems with archived tickets. If this is turned off, archived tickets will not be found by full-text searches.
Ticket::SearchIndex::Attribute
The attribute WordCountMax defines the maximum number of
words which will be processed to build up the index. For example only the
first 1000 words of an article body are stored in the article search
index. The attributes WordLengthMin and
WordLengthMax are used as word length boundaries. Only
words with a length between these two values are stored in the article
search index.
Ticket::SearchIndex::FiltersThere are three default filters defined:
The first filter strips out special chars like: , & < > ?
" ! * | ; [ ] ( ) + $ ^=
The second filter strips out words which begin or ends with one of following
chars: ' : .
The third filter strips out words which do not contain a word-character:
a-z, A-Z, 0-9, _
Ticket::SearchIndex::StopWordsThere are so-called stop-words defined for some languages. These stop-words will be skipped while creating the search index.
There are two different backend modules for the article storage of phone,
email and internal articles (configured via
Ticket::Article::Backend::MIMEBase::ArticleStorage):
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDBThis default module will store attachments in the database.
Don't use it with large setups.
Pro: works with multiple front end servers.
Con: requires much storage space in the database.
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFSUse this module to store attachments on the local file system.
Recommended for large setups.
Pro: Schneller!
Con: If you have multiple front end servers, you must make sure the file system is shared between the servers. Place it on an NFS share or preferably a SAN or similar solution.
You can switch from one back-end to the other on the fly. You can switch the
backend in the SysConfig, and then run the command line utility
bin/otrs.Console.pl Admin::Article::StorageSwitch to
put the articles from the database onto the filesystem or the other way
around. You can use the --target option to specify the
target backend. Please note that the entire process can take considerable
time to run, depending on the number of articles you have and the available
CPU power and/or network capacity.
shell> bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS
Skript: Wechsel des TicketStorage-Backends von Datenbank zu Dateisystem.
If you want to keep old attachments in the database, you can activate the
SysConfig option
Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends
to make sure OTRS will still find them.
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 that match certain criteria can be marked as "archived". These tickets are not accessed if you do a regular ticket search or run a Generic Agent job. The system itself does not have to deal with a huge amount of tickets any longer as only the "latest" tickets are taken into consideration when using OTRS. This can result in a huge performance gain on large systems.
Befolgen Sie folgende Schritte, um die Archivierungsfunktion zu nutzen:
Archivsystem in der SysConfig aktivieren
Wählen Sie in der SysConfig die Gruppe Ticket aus. In
Core::Ticket finden Sie die Option
Ticket::ArchiveSystem, die standardmäßig auf "Nein"
steht. Ändern Sie diese auf "Ja" und speichern Sie die Änderung ab.
Anlegen eines GenericAgent-Jobs
On the Admin page, select GenericAgent and add a new job there.
Job-Einstellungen
Geben Sie dem Job einen geeigneten Namen und angemessene Optionen.
Ticket-Filter
Der Ticketfilter ist eine Ticketsuche, die Tickets nach bestimmten Kriterien auswählt. Es könnte empfehlenswert sein, nur Tickets zu archivieren, die seit einigen Monaten im Status "geschlossen" sind.
Ticket-Aktion
Im Abschnitt "Ticket-Aktion" werden Sie eine Aktion "Ausgewählte Tickets archivieren" finden. Wählen Sie dort "Tickets archivieren" aus.
Job speichern
Am Ende der Seite finden Sie einen Knopf zum Speichern des Jobs.
Betroffene Tickets
Das System wird dann alle Tickets anzeigen, die beim Ausführen des GenericAgent-Jobs archiviert werden.
Ticketsuche
Wenn Sie nun nach Tickets suchen, werden standardmäßig nur Tickets gefunden, die nicht archiviert sind. Wenn Sie auch in archivierten Tickets suchen wollen, fügen Sie "Archivsuche" zu Ihren Suchkriterien hinzu.
OTRS caches a lot of temporary data in
/opt/otrs/var/tmp. Please make sure that this uses a
high performance file system/storage. If you have enough RAM, you can also
try to put this directory on a ramdisk like this:
shell> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
shell> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
shell> sudo mount -o size=16G -t tmpfs none /opt/otrs/var/tmp
# add persistent mount point in /etc/fstab
Please note that this will be a non-permanent storage that will be lost on server reboot. All your sessions (if you store them in the filesystem) and your cache data will be lost.
There is also a centralized memcached based cache backend available for purchase from OTRS Group.