Book:OTRS 3.0 - Admin Manual/Chapter 21/1

There are several options to improve OTRS performance.

TicketIndexModule
There are two backend modules for the ticket index:


 * Using Kernel::System::Ticket::IndexAccelerator::RuntimeDB (default), 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 works like a view. Use bin/otrs.RebuildTicketIndex.pl for generating an initial index build after switching backends.

You can change the IndexAccelerator via SysConfig.

TicketStorageModule
There are two different backend modules for the ticket/article storage:


 * Configure Kernel::System::Ticket::ArticleStorageDB (default) to store attachments, etc. in the database. Note: Don't use it with large set ups.
 * Pro: If your webserver user isn't the '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. E.g. Configure MySQL with "set-variable = max_allowed_packet=8M" to store 8 MB objects (the default is 2M).
 * Configure Kernel::System::Ticket::ArticleStorageFS to store attachments etc. on the local file system. Note: Recommended for large setups.
 * Pro: It is fast!
 * Con: Your web server user should be the 'otrs' user. Also, if you have multiple front-end servers, you should make sure the filesystem is shared between the servers. So place it on an NFS share or preferably a SAN or similar solution.

Archiving Tickets
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 mean 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 Ticket. In Core::Ticket you find the option Ticket::ArchiveSystem 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.   Job Settings Provide a name for the archiving job, and select proper options to schedule this job. 

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

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

 Affected tickets The system will display all tickets which will be archived when executing the Generic Agent job.  

</li>

 Ticket Search 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. </li> </ol>