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 ticket table. You will not have performance trouble till ~ 50.000 tickets in your system.
Kernel::System::Ticket::IndexAccelerator::StaticDB, the most powerfull module, it should be used over 50.000 tickets in a system - use a extra ticket_index table, works like a view. Use bin/RebuildTicketIndex.pl for initial index building.
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 into the database. Note: Don't use it for larger setups.
Pro: If your webserver user isn't the otrs user, use this module to have no 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!).