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 via 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 having about 60.000 tickets (till 6.000 open tickets) in your system.
Kernel::System::Ticket::IndexAccelerator::StaticDB, the most powerful module, it should be used 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.
You have two backend modules for the ticket/article storage .
Kernel/Config.pm
[...] $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB'; [...] |
Kernel::System::Ticket::ArticleStorageDB (default), store attachments and co in the database. Note: Don't use it for larger setups.
Pro: If your webserver user isn't the otrs user, use this module to avoid file permission problems.
Contra: It's not really nice 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 and co in local file system. Note: Use it for larger setups.
Pro: Faster!
Contra: Your webserver user should be the otrs user (file system permissions!).
Note: If you use OTRS 1.2 or higher, the you can switch from one to the other backend on the fly.