21.1. OTRS

From open-support.info

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.

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 otrs.ArticleStorageSwitch.pl to put the articles from the database onto the filesystem or the other way around. You can use the -s and -d options to specify the source and destination back-ends. Please note that the whole 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.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS

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:

1. 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.
   
2. Define a GenericAgent job
   On the Admin page, select GenericAgent and add a new job there.
   1. Job Settings
      Provide a name for the archiving job, and select proper options to schedule this job.
      
   2. 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.
      
   3. Ticket Action
      In this section, set the field labeled "Archive selected tickets" to "archive tickets".
      
   4. Save the job
      At the end of the page you will find an option to save the job.
      
   5. Affected tickets
      The system will display all tickets which will be archived when executing the Generic Agent job.
      

   
   

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