OTRS 1.1 - Manual
Prev |  | Next

# Chapter 20. Performance Tuning

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

Prev | Home | Next
Multi Setup |  | Database