Performance Tuning

There is a list of performance enhancing techniques for your OTRS installation, including configuration, coding, memory use, and more.

Ticket Search Index

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 this command:

otrs> /opt/otrs/bin/ 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:


Basic full-text index settings.

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

Ticket::SearchIndex::Attribute Setting


Run the following command in order to generate a new index:

otrs> /opt/otrs/bin/ Maint::Ticket::FulltextIndexRebuild

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.

WordLengthMin and WordLengthMax

Used as word length boundaries. Only words with a length between these two values are stored in the article search index.


Full-text index regular expression filters to remove parts of the text.

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

Ticket::SearchIndex::Filters Setting

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, _


English stop words for full-text index. These words will be removed from the search index.

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

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

There are so-called stop-words defined for some languages. These stop-words will be skipped while creating the search index.

See also

If your language is not in the system configuration settings or you want to add more words, you can add them to this setting:

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

Article Storage

There are three different back end modules for the article storage of phone, email and internal articles. The used article storage can be configured in the setting Ticket::Article::Backend::MIMEBase::ArticleStorage.


This default module will store attachments in the database. It also works with multiple front end servers, but requires much storage space in the database.


Don’t use this with large setups.


Use this module to store attachments on the local file system. It is fast, but 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.


Recommended for large setups.


Use this module to store attachments in any AWS S3 compatible object storage.

There is a default connection setup to the AWS S3 file storage in Kernel/Config/ To activate the connection for your environment you have to add the following code snippet to Kernel/

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

$Self->{'Ticket::Article::Backend::MIMEBase::ArticleStorageAmazonS3'} = {
    'Active'            => 1,
    'Endpoint'          => '',
    '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,

You can switch from one back end to the other on the fly. You can switch the back end in the system configuration, and then run this command line utility to put the articles from the database onto the file system or the other way around:

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

You can use the --target option to specify the target back end.


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.

To ensure that you have access to all articles during the migration process you can use the Ticket::Article::Backend::MIMEBase::ArticleStorageBackendCheckOrder system configuration setting. This setting specifies additional article storage back ends to be checked for articles and their attachments. It is recommended to add here the old article storage back end.

Tuning the Web Server

The built-in web server of OTRS can handle small and medium setups out of the box. When OTRS serves many users simultaneously, it may be necessary to tweak the web server configuration to increase the number of worker processes, for example.

The web server configuration file is located in Kernel/WebApp.conf, and all settings there are documented. The worker setting can be increased to deploy more processes for serving HTTP requests on capable servers.


OTRS caches a lot of temporary data in /opt/otrs/var/tmp. Please make sure that this uses a high performance file system and storage. If you have enough RAM, you can also try to put this directory on a ramdisk like this:

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


Add persistent mount point in /etc/fstab.


This will be a non-permanent storage that will be lost on server reboot. All your sessions (if you store them in the file system) and your cache data will be lost.


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.

Limits of Objects

There is no technical limitation of how many objects can be used in the system but using high number of objects may affect the system performance. The proposed limits apply only to objects that are set as valid. The objects set as invalid or invalid-temporarily are not used by the system.

To keep the system fast and responsive the following limits for valid objects should not be exceeded:

  • Mail accounts: 10

  • Postmaster filters: 50

  • ACLs: 80

  • Dynamic fields: 300

  • Dynamic field dropdown or multiselect values per field: 100

  • Services: 500

  • SLAs: 50

  • Queues: 200

  • Configuration item classes: 20

  • Configuration item objects: 20,000

  • Processes: 50

  • Generic agents: 30 (frequency max once per hour per generic agent)

  • Ticket states: 20

  • Ticket types: 10

  • Appointment calendars: 50

  • Articles per ticket: 500

Scroll to Top