Table of Contents
Presented below is a list of performance enhancing techniques for your OTRS installation, including configuration, coding, memory use, and more.
There are several options for improving OTRS performance.
There are two backend modules for the index for the ticket queue view:
This 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.
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.
This module helps to extend your articles full-text search (From, To, Cc, Subject and Body search). There are two backend modules for the search index:
This is the default option, and will will do full-text searches on live data (it works fine for up to 50,000 tickets).
This module will strip all articles and build an index after article creation, increasing performance of full-text searches up to 50%.
You can change the used SearchIndexModule via SysConfig.
To create an initial index, use
For StaticDB module, there are some options available for fine tuning:
The attribute "WordCountMax" defines the maximum 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.
There 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, _
There 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 ticket/article storage:
This default module will store attachments in the database.
Don't use it with large setups.
Pro: If your web server isn't running under 'otrs' user, use this module to avoid file permission problems.
Con: It is not advisable to store attachments in your database. Take care that your database
is able to store large objects. I.e.: configure MySQL with
set-variable = max_allowed_packet=8M to store 8 MB objects (the default
Use this module to store attachments on the local file system.
Recommended for large setups.
Pro: It is fast!
Con: Your web server should run under the 'otrs' user. Also, if you have multiple front-end servers, you must make sure the filesystem 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
shell> bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS
Script: Switching storage back-ends from database to filesystem.
If you want to keep old attachments in the database, you can activate the SysConfig option
Ticket::StorageModule::CheckAllBackends to make sure OTRS will still find them.
As OTRS can be used as an audit-proof system, deleting closed tickets may not be a good idea. Therefore we implemented a feature that allows you to archive tickets.
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.
To use the archive feature simply follow these steps:
Activate the archive system in SysConfig
In the Admin page, go to SysConfig and select the group
Core::Ticket you find the option
which is set to "no" by default. Change this setting to "yes" and save this change.
Define a GenericAgent job
On the Admin page, select GenericAgent and add a new job there.
Provide a name for the archiving job, and select proper options to schedule this job.
The ticket filter is searches for tickets that match the selected criteria. It might be a good idea to only archive those tickets in a closed state that have been closed a few months before.
In this section, set the field labeled "Archive selected tickets" to "archive tickets".
Save the job
At the end of the page you will find an option to save the job.
The system will display all tickets which will be archived when executing the Generic Agent job.
When you search for tickets, the system default is to search tickets which are not archived. If you want to search through archived tickets also, simply add "archive search" while defining search criteria.
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.