Table of Contents
Abstract
An exhaustive list of various techniques you might want to use to get the most performance possible out of your OTRS system: configuration, coding, memory use and more.
There are several options to improve the performance of OTRS.
You have two backend modules for the ticket index.
Kernel/Config.pm
[...] $Self->{TicketIndexModule} = 'Kernel::System::Ticket::IndexAccelerator::RuntimeDB'; [...]
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 tickets (with 6,000 open tickets) in your system.
Kernel::System::Ticket::IndexAccelerator::StaticDB, the most powerful module, it should be used when you have above 80,000 tickets (more than 6,000 open tickets) - use an extra ticket_index table, works like a view. Use bin/RebuildTicketIndex.pl for an initial index build.
There are two different backend modules for the ticket/article storage.
Kernel/Config.pm
[...] $Self->{Ticket::StorageModule} = 'Kernel::System::Ticket::ArticleStorageDB'; [...]
Kernel::System::Ticket::ArticleStorageDB (default), store attachments etc. in the database. Note: Don't use it for larger set ups.
Pro: If your webserver user isn't the otrs user, use this module to avoid file permission problems.
Contra: It's not really advisable to store attachments in your database. Take care that your database is able to store large objects. E.g. MySQL (config) "set-variable = max_allowed_packet=8M" to store 8 MB objects (default is 2M).
Kernel::System::Ticket::ArticleStorageFS, store attachments etc. on the local file system. Note: Use it for larger set ups.
Pro: Faster!
Contra: Your web server user should be the otrs user (file system permissions!).
Note: you can switch from one to the other backend on the fly.