RT Performance

RT und Performance ist ein Thema was mir etliche Monate den Schlaf geraubt hat.  Wenn man “nur” der default Installation folgt, hat man zwar ein laufendes System, welches aber sicher fernab allem ist, was man performant nennt. Kritisch wird es dann, wenn da einige User auf dem System arbeiten und man auch mehr als eine Hand voll Queues hat.

Was ich hiermit sagen will, ja - Out of the Box - ist es ok für kleinere Installationen, aber für ein System, was mit 30.000 oder mehr Usern umgehen soll, muss man einiges beachten. Ein paar Kernpunkte will ich hier mal aufführen und auf den weiteren Seiten auch bei dem einen oder anderen mehr ins Detail gehen.

Fangen wir aber mal einfach ein und schauen uns im Detail an, wo man genau schrauben kann.

Hardware und Setup

Die Hardware Entscheidung für das System ist die Grundlage für die spätere Performance des RT (aber was sage ich, das ist bei fast jeder Software so). Wir sollten hier aber auf jeden Fall abwägen was wir mit dem RT erreichen wollen.

Am einfachsten ich erkläre das mal anhand von drei Beispielen die wir in der Vergangenheit implementiert haben. Die Userangaben stellen die Anzahl der User dar, die im RT als “privileged” markiert sind, wovon etwa 30% gleichzeitig im System angemeldet sind.

  1. Ein RT für eine kleine Gruppe von Usern. Die Daten werden nicht für die Ewigkeit aufgehoben, also regelmässig aus dem System gelöscht.
    1. Wir haben vor einiger Zeit einen RT als Workflow System implementiert, der für 400 User als Support für die tägliche Arbeit wichtige Prozesse übernimmt.
    2. Die Daten des RT werden am Ende des Prozesses extern als PDF archiviert (in einem optischen Archiv) und aus dem RT gelöscht (mit dem RTx-Shredder) - die Datenbank bleibt also etwa gleich gross und liegt im Bereich von kleiner 1 GB
    3. Aufgrund der kleinen DB ist die IO Load relativ klein, die DB kann komplett im RAM geladen werden.
  2. Ein RT für eine kleine Firma der Support Anfragen übernimmt und etwa 2000-5000 User hat. Die Daten werden über einen längeren Zeitraum aufbewahrt.
    1. Dieses Setup beschreibt genau unseren RT den wir performant betrieben haben bis zu einer User Grenze von etwa 5000 Usern.
    2. Die Daten wurden für einen Zeitraum von damals geplanten 7 Jahren im RT vorgehalten.
    3. Die Datenbank hatte etwa eine grösse von 50 GB. Daher benötigten wir hier ein performantes DB Backend.
  3. Unser aktueller Firmen RT für eine Anzahl von momentan 38.000 Usern und einer Datenaufbewahrung (für einige Bereiche) von 30 Jahren. Hier wird mittlerweile nicht mehr nur “reines” Trouble Ticketing betrieben sondern für fast alle Bereiche auch Workflows abgebildet (Stichtwort: ITIL, SOX u.a.)
    1. Das ist unser aktuelles Setup. Dieses Setup machte erstmalig einen System Wechsel nötig.
    2. Die Datenhaltung richtet sich hier nach den Anforderungen der jeweiligen Queue
    3. Die Datenbank Ist auf weit über 100GB angewachsen.
    4. Die DB Zugriffe sind massivst IO lastig.

Nachdem wir hier also mal 3 Szenarien abgebildet haben, schauen wir uns nun mal die Umsetzung dieser in technischer Form an. Wir haben für jedes Szenario MySQL als Backend verwendet, für Oracle mag das alles anders aussehen, was ich aber magenls Oracle Erfahrung nicht sagen kann.

  1. Hardware Setup für unseren Workflow RT
    1. Vorraussetzung: Ausfall sicherer Aufbau, shared System auch für andere kleine Anwendungen
    2. Wir haben uns hier für eine VM basierte Lösung mit dem ESX Server entschieden - 64 BIT Mode im ESX Server aktvieren!
    3. Zwei identische Server (Intel) mit maximalem Ausbau (RAM, CPU, RAID) - 64 BIT
    4. Phys. Server: VM0 und VM1
    5. Log. Server: rtwww2 + rtdb1 auf VM0 und rtwww1 + rtdb2 auf VM1
    6. rtwww1 + rtwww2 stellen die Webserver dar, welche über Loadbalancing auf die Produktiv rtdb1 zugreiffen.
    7. rtdb1 und rtdb2 stellen ein MySQL Master/Master Setup dar (Achtung, es wird aber nur der rtdb1 im normal Fall genutzt - Einstellung in der RT_SiteConfig.pm!)
    8. Die Webserver mit genug Speicher versorgen (in unserem Fall 2 GB pro Server) und die DB Server mit ausreichend Speicher um die DB im RAM zu halten und genug plat für Temp Tables zu haben. Wir haben uns hier für 4 GB pro System etnschieden.
    9. Wichtig in diesem Setup: Erstmal einige Zeit das Verhalten der DB beobachten, wenn die DB nicht mehr in den RAM passt oder es gar zu IO Waits kommt, sicherstellen, das die DB genug RAM bekommt.
  2. Hardware Setup für unseren RT bis zu 5000 User
    1. Dieses Setup unterscheidet sich von dem aus Punkt 1 nur in dem Punkt, dass wir hier keine VM Server einsetzen sondern wirklich physikalische Systeme.
    2. Die Datenbank hat einiges an Queries wegzuschaufeln, daher sollte das Plattensystem/RAID relativ fix sein, damit die DB ihre Zeit nicht nur mit warten auf die Festplatten verbringt.
    3. Vom Hardware Sizing haben wir damals für die WebServer 2 Prozessor Systeme mit 4 GB RAM verwendet, GB Ethernet ist ein wichtiger Punkt und ansonsten sind die eher unkritisch.
    4. Die Datenbank Server waren mit 4 Prozessoren ausgestattet, welche aus einem RAM Pool von 8 GB sich bedienen konnte.
    5. Da man in dieser Grössenordnung leider nicht mehr die komplette DB im RAM halten kann, muss man im Verlauf der Nutzung sich auf jeden Fall mit einigen DB Optimierungen und vor allem mit DB Indexen vertraut machen. Der RAM sollte auf jeden Fall für Queries und Temp Tables reserviert werden.
  3. Hardware Setup für unseren RT mit bis dato 38.000 User
    1. Mehrere kleine Webserver, idealer Weise ein Blade Center, welches per Loadbalancing angesprochen wird. Jeder Webserver braucht nicht dringend so “fett” ausgestattet sein, da macht es dann die Masse
    2. Wesentlich kritischer in unserem aktuellen Setup war das DB Backend. Hier hatten wir aus Punkt 2 mit einigen Problemen zu kämpfen:
      1. Das Plattensystem war nicht mehr in der Lage die geforderten Daten in kurzer Zeit zur Verfügung zu stellen, die Folge waren massive IO Waits
      2. Die CPU’s waren kontinuierlich 100% mit den Queries beschäftigt
    3. Um diese Probleme in den Griff zu bekommen, standen wir damals vor der Wahl einen MySQL Cluster zu bauen oder auf komplett andere Hardware zu switchen, welche solchen Anforderungen gewachsen ist. Wir haben uns für andere Hardware (IBM pSeries) entschieden, da die MySQL Cluster Lösung uns einen zu hohen administrativen Aufwand abverlangt hätte (die DB muss verteilt über die Systeme im RAM gehalten werden etc.)
    4. Im Bereich Plattensystem konnten wir so auch gleich die SAN Lösung für unsere pSeries nutzen, was auch den IO Bereich wieder erheblich verbessert hat.
    5. Weniger schön an diesem Setup ist allerdings die HA Lösung. Hatten wir vorher nur kurze, bis gar keine Offline Zeiten im Fall einer Übernahme (Fehler gemerkt, RT_SiteConfig.pm angepasst, Server neu gestartet - per Überwachungsscript) mussten wir jetzt auf die bereits bestehende HACMP Lösung zurück greiffen, welche im Fehlerfall erst die Plattensysteme und Netzwerk Informationen übernimmt und dann die DB neu hoch fährt (was in unserem Fall einige Minuten dauert - 20 um genau zu sein) - allerdings ist dieser Fall bis dato nicht eingetreten, oder wenn, dann nur durch eine gewollte Übernahme
    6. Ein weiterer, riesiger Vorteil dieser Architektur - man kann einfach neue Prozessoren oder RAM dazu “stecken” denn diese Kisten haben die Möglichkeit mehr als 4 oder 8 CPU’s zu verwenden.
    7. Wir verwenden momentan 6 Power5 Prozessoren und 20 GB RAM - die DB hat eine Auslastung von 60% im Mittel momentan.

Dieses waren jetzt nur 3 Beispiele, wie man das Hardware Sizing für einen RT in etwa betrachten kann. Die Werte stammen übrigens aus unserem RT und sind über die letzten 7 Jahre gemessen worden.

Zu der Performance: Wir haben gegenübern unseren Anwendern “garantiert”, dass “normale” Aktionen im RT weniger als 2sec benötigen, also Ticket öffnen, reply etc. Suchen sind davon ausgenommen. Diese Standard Aktionen messen wir auch kontinuierlich mit Cacti genau wie den Verlauf der User Anzahl und vieles andere.

Software Setup

Beim Software Setup gibt es eigentlich nicht allzuviel zu beachten. Es sollten auf jeden Fall die aktuellsten Versionen verwendet werden, dieses gilt vor allem für MySQL. (Da gab es einige Versionen im 5.x Release mit einem defekten Query Optimizer, das bricht einem beim RT dann das Genick!)

Ich empfehle weiterhin die Installation der PERL Module per Hand oder über das “make fixdeps” Script vom RT. Hier wenn möglich nicht die teilweise sehr veralteten RPM’s aus den Distributionen nehmen, das spart Euch echt Nerven.

Ein wichtiger Punkt hier ist aber folgender: Nehmen wir mod_perl oder mod_fastcgi oder mod_fcgid?

Ich würde wirklich jedem abraten mod_perl zu verwenden, das ist wirklich grotten langsam. mod_fastcgi, wenngleich auch schon ein wenig angestaubt, ist da definitiv die bessere Wahl und wesentlich performanter. Leider wird es seit einiger Zeit nicht mehr ernsthaft weiter entwickelt und hat leider auch einige kleine Bugs, die man aber in den Griff bekommt.

Ganz neu ist hier auf jeden Fall mod_fcgid, ein Nachfolger für mod_fastcgi. Meine Tests mit mod_fcgid waren bis jetzt recht erfolgreich, so dass man es auch ruhigen Gewissens einsetzen kann.

Netzwerk Setup

Ein weiterer wichtiger Punkt ist hier das Netzwerk Setup. Wenn man die Webserver und die DB des RT auf separate Kisten verteilt, dann sollte man daran denken, diese so performant wie irgend möglich mit einander zu verbinden.

Desweiteren sollten die Webserver nicht über die gleichen Interfaces mit der DB kommunizieren auf denen auch die User Requests beim Webserver aufschlagen.

Schlusswort

Letzendlich kann man beim RT auch nur das sagen, was für jede Applikation gilt: Will man das Ding schnell laufen haben, dann sollte man auf jeden Fall auch Zeit und Geld investieren. Geld definitiv in Hardware und Support und Zeit in die Optimierung, sehr viel Zeit.

Mit deiner Unterschrift in den Bundestag!