<chapter id="performance-tuning">
<title>Performance Tuning</title>
<para>
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.
</para>

<section id="performance-tuning-otrs">
<title>OTRS</title>
<para>
There are several options to improve the performance via OTRS.
</para>

<section id="performance-tuning-otrs-index">
<title>TicketIndexModule</title>
<para>
You have two backend modules for the ticket index.
</para> 
<para>
Kernel/Config.pm
<programlisting>
[...]
    $Self->{TicketIndexModule} = 'Kernel::System::Ticket::IndexAccelerator::RuntimeDB';
[...]
</programlisting>
</para> 

<para>
<itemizedlist mark='opencircle'>

<listitem>
<para>
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. 
</para>
</listitem>

<listitem>
<para>
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.
</para>
</listitem>

</itemizedlist>

</para>
</section>


<section id="performance-tuning-otrs-storage">
<title>TicketStorageModule</title>
<para>
You have two backend modules for the ticket/article storage .
</para> 
<para>
Kernel/Config.pm
<programlisting>
[...]
    $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB';
[...]
</programlisting>
</para> 

<para>
<itemizedlist mark='opencircle'>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageDB (default), store attachments and co 
into the database. Note: Don't use it for larger setups. 
</para>
<para>
Pro: If your webserver user isn't the otrs user, use this module to have no 
file permission problems.
</para>
<para>
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). 
</para>
</listitem>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageFS, store attachments and co in local 
file system. Note: Use it for larger setups.
</para>
<para>
Pro: Faster! 
</para>
<para>
Contra: Your webserver user should be the otrs user (file system permissions!). 
</para>
</listitem>

</itemizedlist>

</para>
</section>

</section>


<section id="performance-tuning-database">
<title>Database</title>
<para>
This depends on the database you are using. If you have trouble, read the 
documentation for your database or ask your database admin.
</para>

<section id="performance-tuning-database-mysql">
<title>MySQL</title>
<para>
If you use MySQL table type MyISAM (which is default) and have deleted a 
large part of a table or if you have made many changes to a table with 
variable-length rows (tables that have VARCHAR, BLOB, or TEXT columns)
you need to defragment the datafile (tables) by "optimize" command.
</para>
<para>
You should try it if mysqld needs a lot of your CPU time. Optimize table
ticket, ticket_history and article.
<programlisting>
mysql> optimize table ticket;
mysql> optimize table ticket_history;
mysql> optimize table article;
</programlisting>
</para>
</section>

</section>


<section id="performance-tuning-webserver">
<title>Webserver</title>
<para>
Of course you should use mod_perl (
<ulink url="http://perl.apache.org/">http://perl.apache.org/</ulink>). 
It's much faster (~ * 100) than pure cgi. But needs more RAM. So your 
httpd with mod_perl will be about 16 MB (~10MB shared). 
</para>

<section id="performance-tuning-webserver-db">
<title>Preestablish datababase connections</title>
<para>
And you can have establish datababase connections on process startup (httpd). 
This saves also time (see README.webserver).
</para>
</section>

<section id="performance-tuning-webserver-startup">
<title>Preloaded modules - startup.pl</title>
<para>
Use the scripts/apache-perl-startup.pl startup script for preloaded/precompiled perl 
modules on your mod_perl webserver to be faster and smaller (see README.webserver).
</para>
</section>

<section id="performance-tuning-webserver-reload">
<title>Reload perl modules when updated on disk</title>
<para>
Per default Apache::StatINC (mod_perl1) or Apache::Reload (mod_perl2) is used
in scripts/apache-httpd.include.conf. Disable it and you will get 8 % more
speed. But remember to restart the webserver if you change the Kernel/Config.pm
or any other modules!
</para>
</section>

<section id="performance-tuning-webserver-strategy">
<title>Choosing the Right Strategy</title>
<para>
If you have a really large installation (over 1000 new tickets a day and over 40 
Agents) is a good idea to read "Choosing the Right Strategy" 
(<ulink url="http://perl.apache.org/docs/1.0/guide/strategy.html">http://perl.apache.org/docs/1.0/guide/strategy.html</ulink>).
</para>
</section>

<section id="performance-tuning-webserver-gzip">
<title>mod_gzip</title>
<para>
Anyway, if your bandwidth is a little bit small use mod_gzip 
(<ulink url="http://www.schroepl.net/projekte/mod_gzip/">http://www.schroepl.net/projekte/mod_gzip/</ulink>). 
If you have a html page with 45k, mod_gzip compress it. The page will be 
about 7k. That's really nice.
</para>
</section>
</section>

</chapter>
