<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!-- $Id: performance-tuning.xml,v 1.6 2006/04/13 10:13:47 ho Exp $ -->

<chapter id="performance-tuning">
<title>Leistungsverbesserung</title>

<abstract>
<para>
Eine erschpfende Liste verschiedener Techniken, um das Maximum an Leistung aus Ihrem OTRS System herauszuholen: Konfiguration, Programmierung, Speichernutzung und mehr.
</para>
</abstract>

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

<sect2 id="performance-tuning-otrs-index">
<title>TicketIndexModule</title>
<para>
Zur Verfgung stehen zwei Hintergrundmodule fr 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 leistungsfhigste 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). Fhren Sie bin/RebuildTicketIndex.pl zum erstmaligen Aufbau des Index aus.
</para>
</listitem>

</itemizedlist>

</para>
</sect2>


<sect2 id="performance-tuning-otrs-storage">
<title>TicketStorageModule</title>
<para>
Es stehen zwei Module fr 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 Anhnge &amp; Co. in der Datenbank. Merke: Benutzen Sie diese Option nicht fr grere Systeme.
</para>
<para>
Pro: Ist der Benutzer, unter dem der Webserver luft, nicht der OTRS Benutzer, knnen Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden.
</para>
<para>
Contra: Es ist nicht wirklich nett, Anhnge in Ihrer Datenbank zu speichern. Achten Sie darauf, dass Ihre Datenbank das kann. Fr MySQL setzen Sie in dessen Konfiguration bspw.
"set-variable = max_allowed_packet=8M", um 8 MB groe Objekte zu speichern (Standard ist 2M).
</para>
</listitem>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageFS, speichere Anhnge &amp; Co. im lokalen Filesystem ab. Merke: Benutzen Sie dies fr groe Installationen.
</para>
<para>
Pro: Schneller!
</para>
<para>
Contra: Der Benutzer, unter dem der Webserver luft, sollte der OTRS Benutzer sein (Dateisystemberechtigungen!).
</para>
</listitem>

</itemizedlist>

</para>

<para>
Note: Ab OTRS 1.2 oder hher, kann man das TicketStorageModule im Betrieb ndern!
</para>

</sect2>

</sect1>


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

<sect2 id="performance-tuning-database-mysql">
<title>MySQL</title>
<para>
Wenn Sie den Tabellentyp MyISAM (Standard) benutzen, und einen groen Teil einer Tabelle gelscht haben, oder wenn Sie sehr viele nderungen an einer Tabelle mit Zeilen variabler Lnge 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>
shell$ mysql -u user -p datbase
mysql$ optimize table ticket;
mysql$ optimize table ticket_history;
mysql$ optimize table article;
</programlisting>
</para>
</sect2>

<sect2 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 gengend, empfehlen wir, Fragen auf der "PostgreSQL Performance Mailing Liste" zu stellen. Die Teilnehmer der PostgreSQL Liste sind sehr freundlich und knnen wahrscheinlich helfen.
<ulink url="http://www.postgresql.org/lists.html">http://www.postgresql.org/lists.html</ulink>.
</para>
</sect2>

</sect1>


<sect1 id="performance-tuning-webserver">
<title>Webserver</title>
<para>
Natrlich empfehlen wir mod_perl 2.0 (
<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 grer sein.
</para>

<sect2 id="performance-tuning-webserver-db">
<title>Datenbank Verbindung</title>
<para>
Sie knnen die Datenbankverbindung bereits beim Start des httpd-Proze herstellen lassen - dies spart ebenso Zeit (siehe auch README.webserver).
</para>
</sect2>

<sect2 id="performance-tuning-webserver-startup">
<title>Vorgeladene Module - startup.pl</title>
<para>
Nutzen Sie das Start Skript scripts/apache-perl-startup.pl (mod_perl 1.0) bzw. scripts/apache2-perl-startup.pl (mod_perl 2.0), um die Perl Module vorzuladen (siehe README.webserver).
</para>
</sect2>
<sect2 id="performance-tuning-webserver-reload">
<title>Perl Module bei nderung neu laden</title>
<para>
Standardmig wird Apache::Reload (mod_perl 1.0) bzw. Apache2::Reload (mod_perl 2.0) in scripts/apache2-httpd.include.conf eingesetzt. Deaktivieren Sie es und die Geschwindigkeit steigt um etwa 8%.
Ab nun mssen Sie den Webserver neu starten, wenn Sie irgendetwas ndern!
Wichtig, es hat dadurch zur Folge, dass der OTRS-Paket-Manager nicht mehr ber das Web-Interface bedient werden kann (nur noch ber CMD - bin/opm.pl).
</para>
</sect2>

<sect2 id="performance-tuning-webserver-strategy">
<title>Die richtige Strategie whlen</title>
<para>
Bei wirklich groen Installationen (ber 1000 neue Tickets am Tag, 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>
</sect2>

<sect2 id="performance-tuning-webserver-gzip">
<title>mod_gzip/mod_deflate</title>
<para>
Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_gzip fr Apache1
(<ulink url="http://www.schroepl.net/projekte/mod_gzip/">http://www.schroepl.net/projekte/mod_gzip/</ulink>) bzw. mod_deflate fr Apache2 (default Modul in Apache2).
Eine HTML-Seite von 45k wird mod_gzip/mod_deflate auf etwa 7k zusammendrcken - nett.
</para>
</sect2>

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

</sect1>

</chapter>