<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 the ticket table. You will not have performance 
trouble until having about 60.000 tickets (till 6.000 open tickets) in your system.
</para>
</listitem>

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

<para>
Note: If you use OTRS 1.2 or higher, the you can switch from one to the other
backend on the fly.
</para>

</section>

</section>


<section id="performance-tuning-database">
<title>Database</title>
<para>
This depends on the database you are using. If you're having 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) with the "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>
<prompt>mysql></prompt><userinput><command>optimize</command> table ticket;</userinput>
<prompt>mysql></prompt><userinput><command>optimize</command> table ticket_history;</userinput>
<prompt>mysql></prompt><userinput><command>optimize</command> table article;</userinput>
</programlisting>
</para>
</section>

<section id="performance-tuning-database-postgresql">
<title>PostgreSQL</title>
<para>
PostgreSQL is best tuned by modifying the postgresql.conf file in your
PostgreSQL data directory. For advice on how to do this, see these
articles:
<ulink url="http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html">http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html</ulink>
<ulink url="http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html">http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html</ulink>
If performance is still not satisfactory, we suggest that you join the
PostgreSQL Performance mailing list and ask questions there. The folks on
the PostgreSQL list are very friendly and can probably help <ulink url="http://www.postgresql.org/lists.html">http://www.postgresql.org/lists.html</ulink>.
</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>
You can have the datababase connections being established 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) it 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 compresses it. The page will be 
about 7k. That's really nice.
</para>
</section>

<section id="performance-tuning-webserver-dos">
<title>mod_dosevasive</title>
<para>
If you want to block http DoS (Denail of Service) attacks, use mod_dosevasive.
(<ulink url="http://www.nuclearelephant.com/projects/dosevasive/">http://www.nuclearelephant.com/projects/dosevasive/</ulink>). 
</para>
</section>

</section>

</chapter>
