<chapter id="performance-tuning">
<title>Leistungsverbesserung</title>
<para>
Eine ersch&ouml;pfende Liste verschiedener Techniken, um das Maximum an Leistung aus Ihrem OTRS System zu bekommen: Konfiguration, Programmierung, Speichernutzung und mehr.
</para>

<section id="performance-tuning-otrs">
<title>OTRS</title>
<para>
Im folgenden fineden Sie die Optionen, die Leistung des Systems via OTRS selbst zu verbessern.
</para>

<section id="performance-tuning-otrs-index">
<title>TicketIndexModule</title>
<para>
Zur Verf&uuml;gung stehen zwei Hintergrundmodule f&uuml;r den 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 (Standard), generiere jede Queue-Ansicht dynamisch aus der Ticket Tabelle. Sie werden keine Probleme mit der Leistung bekommen bis zu etwa 60.000 Tickets (oder 6000 offenen) in Ihrem System.
</para>
</listitem>

<listitem>
<para>
Kernel::System::Ticket::IndexAccelerator::StaticDB, das leistungsf&auml;higste Modul. Es sollte ab 80.000 Tickets oder mehr als 6000 offenen eingesetzt werden. Benutzt eine extra ticket_index Tabelle, arbeitet wie eine Ansicht (View). Führen Sie bin/RebuildTicketIndex.pl zum erstmaligen Aufbau des Index' aus.
</para>
</listitem>

</itemizedlist>

</para>
</section>


<section id="performance-tuning-otrs-storage">
<title>TicketStorageModule</title>
<para>
Es stehen zwei Module f&uuml;r das Speichern der Tickets und Artikel bereit.
</para> 
<para>
Kernel/Config.pm
<programlisting>
[...]
    $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB';
[...]
</programlisting>
</para> 

<para>
<itemizedlist mark='opencircle'>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageDB (Standard), speichere Anh&auml;nge &amp; Co. in der Datenbank. Merke: Benutzen Sie diese Option nicht f&uuml;r gr&ouml;ßere Systeme.
</para>
<para>
Pro: Ist der Benutzer, unter dem der Webserver l&auml;uft, nicht der OTRS Benutzer, k&ouml;nnen Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden.
</para>
<para>
Contra: Es ist nicht wirklich nett, Anh&auml;nge in Ihrer Datenbank zu speichern. Achten Sie darafu, dass Ihre Datenbank das kann. F&uuml;r MySQL setzen Sie in dessen Konfiguration bspw. 
"set-variable = max_allowed_packet=8M", um 8 MB große Objekte zu speichern (Standard ist 2M).
</para>
</listitem>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageFS, speichere Anh&auml;nge &amp; Co. im lokalen Filesystem ab. Merke: Benutzen Sie dies f&uuml;r große Installationen.
</para>
<para>
Pro: Schneller! 
</para>
<para>
Contra: Der Benutzer, unter dem der Webserver l&auml;uft, sollte der OTRS Benutzer sein (Dateisystemberechtigungen!).
</para>
</listitem>

</itemizedlist>

</para>

<para>
Note: Bei OTRS 1.2 oder höher, kann man das TicketStorageModule im Betrieb ändern.
</para>

</section>

</section>


<section id="performance-tuning-database">
<title>Datenbank</title>
<para>
Einstellungen sind immer spezifisch für die jeweils eingesetzte Datenbank. Bei Problemen lesen Sie die Dokumentation und fragen Sie Ihren Datenbankadministrator.
</para>

<section id="performance-tuning-database-mysql">
<title>MySQL</title>
<para>
Wenn Sie den Tabellentyp MyISAM (Standard) benutzen, und einen großen Teil einer Tabelle gel&ouml;scht haben, oder wenn Sie sehr viele &Auml;nderungen an einer Tabelle mit Zeilen variabler L&auml;nge vorgenommen haben (Tabellen mit VARCHAR, BLOB oder TEXT Spalten), sollten Sie die Datendateien mit dem "optimize" Kommando behandeln.
</para>
<para>
Dies bietet sich an, wenn MySQL viel CPU Zeit braucht. Optimieren Sie die Tabellen ticket, ticket_history und 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 konfigurieren Sie am besten in der postgresql.conf Datei in Ihrem PostgreSQL Datenverzeichnis. Hier gibt es Hilfe dazu:
<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>
Ist die Leistung immer noch nicht gen&uuml;gend, empfehlen wir, Fragen auf der "PostgreSQL Performance Mailing Liste" zu stellen. Die Teilnehmer der PostgreSQL Liste sind sehr freundlich und k&ouml;nnen wahrscheinlich helfen.
<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>
Nat&uuml;rlich empfehlen wir mod_perl (
<ulink url="http://perl.apache.org/">http://perl.apache.org/</ulink>). 
Es ist sehr viel schneller (etwa um den Faktor 100) als pures CGI, braucht aber auch mehr Speicher. Ihr httpd wird mit mod_perl also gr&ouml;ßer sein. 
</para>

<section id="performance-tuning-webserver-db">
<title>Datenbank Verbindung</title>
<para>
Sie k&ouml;nnen die Datenbank Verbindung bereits beim Start des httpd-Prozeß herstellen lassen - dies spart ebenso Zeit (siehe auch README.webserver).
</para>
</section>

<section id="performance-tuning-webserver-startup">
<title>Vorgeladene Module - startup.pl</title>
<para>
Nutzen Sie das Start Skript scripts/apache-perl-startup.pl, um die Perl Module vorzuladen (siehe README.webserver).
</para>
</section>

<section id="performance-tuning-webserver-reload">
<title>Perl Module bei &Auml;nderung neu laden</title>
<para>
Standardm&auml;ßig wird Apache::StatINC (mod_perl1) oder Apache::Reload (mod_perl2) in scripts/apache-httpd.include.conf eingesetzt. Deaktivieren Sie es und die Geschwindigkeit steigt um etwa 8%. Ab nun m&uuml;ssen Sie den Webserver neu starten, wenn Sie irgendetwas &auml;ndern!
</para>
</section>

<section id="performance-tuning-webserver-strategy">
<title>Die richtige Strategie w&auml;hlen</title>
<para>
Bei wirklich großen Installationen (&uuml;ber 1000 neue Tickets am Tag, &uuml;ber 40 Agenten) ist es eine sehr gute Idee, den Artikel "Choosing the Right Strategy" (in englisch) zu lesen 
(<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>
Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_gzip 
(<ulink url="http://www.schroepl.net/projekte/mod_gzip/">http://www.schroepl.net/projekte/mod_gzip/</ulink>). 
Eine HTML-Seite von 45k wird mod_gzip auf etwa 7k zusammendr&uuml;cken - nett.
</para>
</section>

<section id="performance-tuning-webserver-dos">
<title>mod_dosevasive</title>
<para>
Um http DoS (Denail of Service) Angriffe zu blocken kann mod_dosevasive
benutzt werden. 
(<ulink url="http://www.nuclearelephant.com/projects/dosevasive/">http://www.nuclearelephant.com/projects/dosevasive/</ulink>).
</para>
</section>

</section>

</chapter>
