OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen

In diesem Guide: OTOBO bei hohem Ticketvolumen schnell halten — Indexing, Caching, Datenbank und Infrastruktur.

Verwandte Themen: Systemkonfiguration · Backup · Version 11 · Hosting

Ein performantes Ticket-System ist die Basis für exzellenten Support. OTOBO (insbesondere ab Version 11) bietet zahlreiche Stellschrauben, um auch bei hohen Ticketvolumina (> 1 Mio. Artikel) blitzschnell zu bleiben.

[!TIP] Quick Win: Nutzen Sie einen StaticDB-Ticketindex und leiten Sie eingehende E-Mails in fokussierte Queues statt in eine Sammel-Queue. Das entlastet das Dashboard und reduziert manuelles Vorsortieren.

---

1. Ticket-Indexmodule

Der Index bestimmt, wie schnell Listenansichten (Dashboard, Queue-Ansicht) geladen werden.

1.1 RuntimeDB (Standard für kleine Instanzen)

• Modul: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Verhalten: Abfragen erfolgen live auf der ticket-Tabelle.
• Limit: Bis ca. 50.000 offene Tickets performant. Danach steigt die Last bei jedem Dashboard-Refresh spürbar.

1.2 StaticDB (Empfohlen für High-Scale)

• Modul: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Vorteil: Nutzt eine dedizierte ticket_index-Tabelle. Schreibvorgänge sind minimal langsamer, Lesezugriffe (Listen) jedoch um Faktoren schneller und konstant.
• Einrichtung:
  1. In der Systemkonfiguration umstellen.
  2. Initialen Index aufbauen:

     /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild

---

2. Suche & Indexierung (Elasticsearch)

Während der interne SQL-Index für kleine Mengen ausreicht, führt bei großen Datenbeständen kein Weg an Elasticsearch vorbei.

2.1 Elasticsearch Tuning (OTOBO Docker-Kontext)

Wenn Sie OTOBO in Docker betreiben (empfohlen für Installation), achten Sie auf die JVM-Einstellungen in Ihrer docker-compose.override.yml:

services:
  elasticsearch:
    environment:
      - ES_JAVA_OPTS=-Xms4g -Xmx4g

• Heap Size: Setzen Sie den Heap auf maximal 50% des verfügbaren RAMs (max. 31GB).
• Disk Watermarks: Elasticsearch schaltet Indizes auf Read-Only, wenn der Festplattenplatz knapp wird (< 5% frei). Monitoring ist hier essenziell.

2.2 Interner Volltextindex (SQL)

Falls Sie kein Elasticsearch nutzen, begrenzen Sie den Umfang:

• WordCountMax: Auf 500-1000 Wörter limitieren (Ticket::SearchIndex::Attribute.WordCountMax).
• Archivierte Tickets: Diese vom Suchindex ausschließen, um die DB-Größe kompakt zu halten.

---

3. Data Storage & Backends

3.1 Artikelspeicher (FS vs. DB)

Standardmäßig speichert OTOBO Anhänge in der Datenbank (ArticleStorageDB).

• Ab 10.000 Tickets oder großen Anhängen: Wechseln Sie zwingend auf ArticleStorageFS.
• Vorteil: Die Datenbank bleibt klein und Backups/Dumps laufen wesentlich schneller.

/opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

3.2 Ticket-Archivierung

Archivieren Sie geschlossene Tickets, die älter als 6-12 Monate sind. Archivierte Tickets werden standardmäßig nicht mehr indexiert, was die tägliche Arbeit massiv beschleunigt.

---

4. Caching & Memory

4.1 Redis (Must-Have)

Verwenden Sie Redis als Caching-Backend anstelle des Dateisystems. Redis hält Konfigurationen und Sessions im RAM.

• SysConfig: Cache::Module auf Redis setzen.
• Expert-Tipp: Nutzen Sie Redis::Fast für noch geringere Latenzen in High-Traffic-Umgebungen.

4.2 Ramdisk für /opt/otobo/var/tmp

Wenn Sie kein Docker nutzen, verschieben Sie das Temp-Verzeichnis in den RAM:

mount -t tmpfs -o size=4G tmpfs /opt/otobo/var/tmp

Beschleunigt das Generieren von PDF-Reports und temporären Artikel-Files.

---

5. Datenbank-Tuning (MariaDB/MySQL)

Für OTOBO 11 empfehlen wir folgende Parameter (bei 16GB+ RAM):

[mysqld]
innodb_buffer_pool_size = 8G         # ca. 50-60% des RAMs
innodb_log_file_size    = 1G          # wichtig für Performance bei Massenupdates
innodb_flush_log_at_trx_commit = 2    # Kompromiss aus Speed und Datensicherheit
max_connections         = 500

[!IMPORTANT] OTOBO 11 nutzt effizientere Queries, profitiert aber extrem von schnellem I/O. Verwenden Sie ausschließlich NVMe-SSDs.

---

6. OTOBO 11 & Docker-Spezifika

OTOBO 11 ist nativ für Docker optimiert.

• Container-Images: Die offiziellen Images sind bereits auf Performance getrimmt (Perl-Level Optimierungen).
• Log-Rotation: Ab Version 11.0.11 verfügt OTOBO über eine integrierte Log-Rotation für otobo.log. Externe Skripte sind für dieses Logfile nicht mehr zwingend erforderlich.
• Auto-Tuning: Die Container erkennen verfügbare Ressourcen oft automatisch, dennoch sollten Limits (mem_limit) in Docker Compose gesetzt werden.

---

7. Monitoring & Früherkennung

Keine Optimierung ohne Daten. Wir empfehlen den Prometheus-Stack:

1. Metrics: Abgreifen der OTOBO Metriken via API.
2. Grafana: Dashboard für:
   • Request-Latenz (SLA Tracking)
   • Queue-Füllstand (Engpässe erkennen)
   • DB-Lock-Wait-Times
3. Alerting: Benachrichtigung, wenn der Cache-Hit-Rate unter 90% fällt oder Elasticsearch-Shards “yellow” werden.

---

Fazit

Performance-Optimierung in OTOBO ist ein Zusammenspiel aus Hardware, Prozessdesign und technischem Feintuning.

Starten Sie mit dem Wechsel auf Elasticsearch, führen Sie eine Archivierung ein und halten Sie Sammel-Queues schlank. So bleibt Ihr OTOBO-System auch bei wachsender Unternehmensgröße reaktionsschnell und stabil.

OTOBO Health-Check & Performance-Tuning

Reagiert Ihr OTOBO träge? Wir analysieren Datenbank, Caching, Indizes und Daemon-Prozesse für maximale Geschwindigkeit.

Health-Check anfragen

Häufig gestellte Fragen

Was sind die ersten Schritte für bessere OTOBO-Performance?

Um die OTOBO-Performance schnell und effektiv zu verbessern, sollten Sie zunächst den StaticDB-Ticketindex aktivieren. Dieser nutzt eine dedizierte ticket_index-Tabelle, die Lesezugriffe auf Ticketlisten erheblich beschleunigt. Parallel dazu ist die Umstellung des Caching-Backends auf Redis ein Muss, da es Konfigurationen und Sessions im RAM hält und somit Latenzen reduziert. Ein weiterer Quick Win ist die Umstellung des Artikelspeichers von ArticleStorageDB auf ArticleStorageFS, sobald Sie mehr als 10.000 Tickets oder große Anhänge haben, um die Datenbank zu entlasten und Backups zu beschleunigen. Zudem empfiehlt es sich, eingehende E-Mails direkt in spezifische Queues zu leiten, um Sammel-Queues zu entlasten und das Dashboard zu beschleunigen.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation

Was sollte ich über 1.1 RuntimeDB (Standard für kleine Instanzen) wissen?

Das RuntimeDB-Modul (Kernel::System::Ticket::IndexAccelerator::RuntimeDB) ist der Standard-Ticketindex für OTOBO-Instanzen mit geringem bis mittlerem Ticketvolumen. Es arbeitet, indem es Abfragen live auf der ticket-Tabelle der Datenbank ausführt. Dieses Verhalten ist bis zu einer Anzahl von etwa 50.000 offenen Tickets performant. Überschreitet die Anzahl der offenen Tickets dieses Limit, kann die Last bei jedem Dashboard-Refresh spürbar ansteigen, da die Datenbank direkt und ohne dedizierten Index abgefragt wird. Für größere Installationen ist daher ein Wechsel auf StaticDB dringend empfohlen, um Performance-Engpässe zu vermeiden.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation

Was sollte ich über 1.2 StaticDB (Empfohlen für High-Scale) wissen?

Das StaticDB-Modul (Kernel::System::Ticket::IndexAccelerator::StaticDB) ist die empfohlene Lösung für OTOBO-Instanzen mit hohem Ticketvolumen und Skalierungsanforderungen. Sein Hauptvorteil liegt in der Nutzung einer dedizierten ticket_index-Tabelle. Während Schreibvorgänge (z.B. neue Tickets erstellen) minimal langsamer sein können, sind Lesezugriffe auf Ticketlisten (wie im Dashboard oder in Queue-Ansichten) um Faktoren schneller und bleiben auch bei Millionen von Tickets konstant performant. Die Einrichtung erfordert die Umstellung in der Systemkonfiguration und den initialen Aufbau des Index mittels des Konsolenbefehls /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild. Dies ist ein entscheidender Schritt zur Entlastung der Hauptdatenbank und zur Sicherstellung einer reaktionsschnellen Benutzeroberfläche.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation

Wie optimiere ich die Suche in OTOBO bei großem Ticketvolumen?

Bei großem Ticketvolumen ist Elasticsearch unerlässlich für eine schnelle Volltextsuche in OTOBO. Eine saubere Konfiguration kann die Suchgeschwindigkeit dramatisch verbessern. Wenn Sie OTOBO mit Docker betreiben, ist das Tuning der JVM-Einstellungen für Elasticsearch entscheidend, z.B. durch Setzen von ES_JAVA_OPTS=-Xms4g -Xmx4g in Ihrer docker-compose.override.yml. Der Heap sollte maximal 50% des verfügbaren RAMs (bis zu 31GB) betragen. Achten Sie zudem auf Disk Watermarks, da Elasticsearch Indizes auf Read-Only schaltet, wenn der Festplattenplatz unter 5% fällt. Falls Sie kein Elasticsearch nutzen, begrenzen Sie den internen SQL-Volltextindex, indem Sie Ticket::SearchIndex::Attribute.WordCountMax auf 500-1000 Wörter limitieren und archivierte Tickets vom Suchindex ausschließen.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Fortgeschrittene Installation von OTOBO mit Docker Compose

Wann sollte ich den Artikelspeicher von Datenbank auf Dateisystem umstellen?

Standardmäßig speichert OTOBO Anhänge in der Datenbank (ArticleStorageDB). Sobald Ihre OTOBO-Instanz jedoch mehr als 10.000 Tickets verwaltet oder regelmäßig große Anhänge verarbeitet, ist ein zwingender Wechsel auf ArticleStorageFS (Artikelspeicher im Dateisystem) erforderlich. Der Hauptvorteil dieser Umstellung ist, dass Ihre Datenbank deutlich kleiner bleibt, was wiederum die Geschwindigkeit von Backups und Datenbank-Dumps massiv beschleunigt und die allgemeine Performance des Systems verbessert. Die Umstellung erfolgt über die OTOBO-Konsole mit dem Befehl /opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS. Dieser Schritt ist entscheidend, um Performance-Engpässe bei wachsendem Datenvolumen zu vermeiden.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation

Welche Rolle spielt Redis für die OTOBO-Performance und wie wird es konfiguriert?

Redis ist ein Must-Have für die OTOBO-Performance, da es als schnelles Caching-Backend anstelle des Dateisystems dient. Durch die Speicherung von Konfigurationen, Sessions und temporären Daten im RAM reduziert Redis die Latenzzeiten erheblich und beschleunigt den Zugriff auf häufig benötigte Informationen. Um Redis zu aktivieren, setzen Sie das Systemkonfigurations-Parameter Cache::Module auf Redis. Für Umgebungen mit sehr hohem Traffic kann die Verwendung von Redis::Fast die Latenzen noch weiter minimieren. Zusätzlich kann die Performance durch das Verschieben des temporären OTOBO-Verzeichnisses (/opt/otobo/var/tmp) in eine Ramdisk (z.B. mount -t tmpfs -o size=4G tmpfs /opt/otobo/var/tmp) weiter gesteigert werden, was besonders das Generieren von PDF-Reports und temporären Artikel-Files beschleunigt.

• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation

Welche Datenbank-Parameter sind für OTOBO 11 und MariaDB/MySQL empfehlenswert?

Für OTOBO 11, insbesondere in Kombination mit MariaDB oder MySQL und Systemen mit 16GB+ RAM, sind spezifische Datenbank-Parameter entscheidend für optimale Performance. Empfohlen werden folgende Einstellungen im [mysqld]-Abschnitt Ihrer Konfigurationsdatei:

• innodb_buffer_pool_size = 8G: Dies sollte etwa 50-60% des verfügbaren RAMs betragen, um häufig genutzte Daten im Speicher zu halten.
• innodb_log_file_size = 1G: Wichtig für die Performance bei Massenupdates und Schreibvorgängen.
• innodb_flush_log_at_trx_commit = 2: Bietet einen guten Kompromiss zwischen Geschwindigkeit und Datensicherheit.
• max_connections = 500: Ermöglicht eine ausreichende Anzahl gleichzeitiger Datenbankverbindungen.
  Es ist zudem von größter Bedeutung, ausschließlich NVMe-SSDs für die Datenbank zu verwenden, da OTOBO 11 extrem von schnellem I/O profitiert.
• OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen
• Performance Tuning – OTOBO Installation Guide 10.1 documentation