Chapter 20. Performance Tuning

Table of Contents
OTRS
Database
Webserver

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.

OTRS

There are several options to improve the performance via OTRS.

TicketIndexModule

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 60.000 tickets in a system - use a extra ticket_index table, works like a view. Use bin/RebuildTicketIndex.pl for initial index build.

TicketStorageModule

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!).