<?xml version='1.0' encoding='UTF-8'?>
<!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.35 2012/02/23 13:44:35 mg Exp $ -->
<chapter id="performance-tuning">
<title>Leistungsverbesserung</title>

<abstract>
<para>
Hier finden Sie eine Liste verschiedener Techniken der Leistungssteigerung
Ihrer OTRS-Installation, einschließlich Konfiguration, Programmierung,
Speichernutzung und mehr.
</para>
</abstract>

<section id="performance-tuning-otrs">
<title>OTRS</title>
<para>
Es gibt verschiedene Ansätze zur Leistungssteigerung von OTRS.
</para>

<section id="performance-tuning-otrs-index">
<title>TicketIndexModule</title>
<para>
Zur Verfügung stehen zwei Backend-Module für den Ticket Index:
</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ä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 <filename>bin/otrs.RebuildTicketIndex.pl</filename> zum
erstmaligen Aufbau des Index aus.
</para>
</listitem>

</itemizedlist>
</para>

<para>
Sie können den IndexAccelerator per SysConfig einstellen.
</para>

</section>

<section id="performance-tuning-otrs-storage">
<title>TicketStorageModule</title>
<para>
Es stehen zwei Module für das Speichern der Tickets und Artikel bereit:
</para>

<para>
<itemizedlist mark='opencircle'>

<listitem>
<para>
Kernel::System::Ticket::ArticleStorageDB (Standard), speichert Anhänge
u. A. in der Datenbank. Merke: Benutzen Sie diese Option nicht für größere
Systeme.
</para>
<para>
Pro: Ist der Benutzer, unter dem der Webserver läuft, nicht der Benutzer
'otrs', können Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden.
</para>
<para>
Contra: Es ist nicht wirklich ratsa,, Anhänge in Ihrer Datenbank zu
speichern. Achten Sie darauf, dass Ihre Datenbank das kann. Fü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, speichert Anhänge u. A. im lokalen
Filesystem ab. Merke: Benutzen Sie dies für große Installationen.
</para>
<para>
Pro: Schneller!
</para>
<para>
Contra: Der Benutzer, unter dem der Webserver läuft, sollte der Benutzer
'otrs' sein (Dateisystemberechtigungen!). Wenn Sie mehrere
OTRS-Frontendserver haben, müssen Sie sicherstellen, dass das Dateisystem
gemeinsam genutzt wird. Sie können es z. B. auf ein NFS-Share oder
vorzugsweise ein SAN oder eine vergleichbare Lösung legen.
</para>
</listitem>

</itemizedlist>

</para>

<para>
	Merke: Sie können während des Betriebs von einem Backend auf das andere
wechseln. Stellen Sie dazu das Backend in der SysConfig um, und führen Sie
<filename>otrs.ArticleStorageSwitch.pl</filename> aus, um die Artikel aus
der Datenbank ins Dateisystem zu überführen oder umgekehrt. Sie können die
<emphasis>-s</emphasis> und <emphasis>-d</emphasis> Option verwenden, um das
Quell- und Zielbackend anzugeben. Der Prozess kann eine ganze Weile dauern,
je nach Menge der Artikel sowie System- und Netzwerkleistung.
</para>

<para>
<programlisting>
shell> bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
</programlisting>
</para>
<para>
<emphasis>Skript: Wechsel des TicketStorage-Backends von Datenbank zu
Dateisystem.</emphasis>
</para>
</section>

<section>
    <title>Tickets archivieren</title>

    <para>
        Da OTRS als revisionssicheres System betrieben werden kann, ist das Löschen
von geschlossenen Tickets möglicherweise nicht empfehlenswert. Daher haben
wir eine Funktion implementiert, mit der Sie Tickets archivieren können.
    </para>
    <para>
        Kokret ist darunter zu verstehen, dass Tickets, die bestimmte Kriterien
erfüllen, als "archiviert" markiert werden. Diese Tickets werden dann bei
regulären Suchabfragen oder von GenericAgent-Jobs nicht mehr erfasst. Somit
muss sich das System mit einer großen Ticketmenge nicht mehr befassen, weil
dann nur noch die "aktuellsten" Tickets betrachtet werden. Das kann auf
großen Systemen eine signifikante Performanceverbesserung bewirken.
    </para>
    <para>
        Befolgen Sie folgende Schritte, um die Archivierungsfunktion zu nutzen:
    </para>
    <orderedlist>
        <listitem>
            <para>
                Archivsystem in der SysConfig aktivieren
            </para>
            <para>
                Wählen Sie in der SysConfig die Gruppe <literal>Ticket</literal> aus.  In
<literal>Core::Ticket</literal> finden Sie die Option
<literal>Ticket::ArchiveSystem</literal>, die standardmäßig auf "Nein"
steht. Ändern Sie diese auf "Ja" und speichern Sie die Änderung ab.
            </para>
        </listitem>
        <listitem>
            <para>
                Anlegen eines GenericAgent-Jobs
            </para>
            <para>
                Wählen Sie im Administrationsbereich den "GenericAgent" aus und legen Sie
dort einen neuen Job an. <orderedlist>
                    <listitem>
                        <para>
                            Job-Einstellungen
                        </para>
                        <para>
                            Geben Sie dem Job einen geeigneten Namen und angemessene Optionen.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Ticket-Filter
                        </para>
                        <para>
                            Der Ticketfilter ist eine Ticketsuche, die Tickets nach bestimmten Kriterien
auswählt. Es könnte empfehlenswert sein, nur Tickets zu archivieren, die
seit einigen Monaten im Status "geschlossen" sind.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Ticket-Aktion
                        </para>
                        <para>
                            Im Abschnitt "Ticket-Aktion" werden Sie eine Aktion "Ausgewählte Tickets
archivieren" finden. Wählen Sie dort "Tickets archivieren" aus.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Job speichern
                        </para>
                        <para>
                            Am Ende der Seite finden Sie einen Knopf zum Speichern des Jobs.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Betroffene Tickets
                        </para>
                        <para>
                            Das System wird dann alle Tickets anzeigen, die beim Ausführen des
GenericAgent-Jobs archiviert werden.
                        </para>
                    </listitem>
                </orderedlist>
            </para>
        </listitem>
        <listitem>
            <para>
                Ticketsuche
            </para>
            <para>
                Wenn Sie nun nach Tickets suchen, werden standardmäßig nur Tickets gefunden,
die nicht archiviert sind. Wenn Sie auch in archivierten Tickets suchen
wollen, fügen Sie "Archivsuche" zu Ihren Suchkriterien hinzu.
            </para>
        </listitem>
    </orderedlist>
</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öscht haben, oder wenn Sie sehr viele Änderungen an einer
Tabelle mit Zeilen variabler Lä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.
</para>

<para>
<programlisting>
shell$ mysql -u user -p database
mysql$ optimize table ticket;
mysql$ optimize table ticket_history;
mysql$ optimize table article;
</programlisting>
</para>

<para>
<emphasis>Skript: Optimierung von Datenbanktabellen.</emphasis>
</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:
</para>

<para>
    <itemizedlist>
        <listitem>
            <para>
            <ulink url="http://www.revsys.com/writings/postgresql-performance.html">
<citetitle>http://www.revsys.com/writings/postgresql-performance.html</citetitle>
</ulink>
            </para>
        </listitem>
        <listitem>
            <para>
            <ulink url="http://varlena.com/GeneralBits/Tidbits/perf.html">
<citetitle>http://varlena.com/GeneralBits/Tidbits/perf.html</citetitle>
</ulink>
            </para>
        </listitem>
        <listitem>
            <para>
            <ulink url="http://varlena.com/GeneralBits/Tidbits/annotated_conf_e.html">
<citetitle>http://varlena.com/GeneralBits/Tidbits/annotated_conf_e.html</citetitle>
</ulink>
            </para>
        </listitem>
    </itemizedlist>
</para>

<para>
Ist die Leistung immer noch nicht genügend, empfehlen wir, Fragen auf der
"PostgreSQL Performance Mailing Liste" ( <ulink
url="http://www.postgresql.org/community/lists/">
http://www.postgresql.org/community/lists/ </ulink> )  zu stellen. Die
Teilnehmer der PostgreSQL Liste sind sehr freundlich und können
wahrscheinlich helfen.
</para>
</section>

</section>

<section id="performance-tuning-webserver">
<title>Webserver</title>
<para>
Natürlich 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 größer sein.
</para>

<section id="performance-tuning-webserver-db">
<title>Persistente Datenbankverbindungen</title>
<para>
Sie können die Datenbankverbindung bereits beim Start des Webservers
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
<filename>scripts/apache2-perl-startup.pl</filename>, um die Perl Module
vorzuladen (siehe README.webserver). Dadurch wird der Webserver schneller
und braucht weniger Speicher.
</para>
</section>
<section id="performance-tuning-webserver-reload">
<title>Perl Module bei Änderung neu laden</title>
<para>
By default Apache::Reload is used in
scripts/apache2-httpd.include.conf. Disable it and you will get 8% more
speed. But remember to restart the web server if you install any modules via
the OTRS Package Manager, or any values in your SysConfig or in
Kernel/Config.pm. Important: this would also mean you can't use the OTRS
Package Manager via the web interface, you need to use the command line
variant - <filename>bin/otrs.PackageManager.pl</filename>.
</para>
</section>

<section id="performance-tuning-webserver-strategy">
<title>Die richtige Strategie wählen</title>
<para>
If you have a larger installation, say over 1,000 new tickets per day and
over 40 agents, it is a good idea to read the chapters on Performance of the
mod_perl User's Guide ( <ulink
url="http://perl.apache.org/docs/2.0/user/index.html"><citetitle>http://perl.apache.org/docs/2.0/user/index.html</citetitle></ulink>
).
</para>
</section>

<section id="performance-tuning-webserver-gzip">
<title>mod_gzip/mod_deflate</title>
<para>
Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_deflate
für Apache2. Eine HTML-Seite von 45k wird mod_gzip/mod_deflate auf etwa 7k
zusammendrücken. Allerdings wird dadurch die Last auf dem Server erhöht.
</para>
</section>

</section>

</chapter>