OTOBO Performance Optimierung & Skalierung

OTOBO Performance Optimierung & Skalierung

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: Integrieren Sie OpenTicketAI. Durch die KI-gestützte Klassifizierung entfällt das manuelle Verschieben von Tickets aus der “Raw”-Queue. Dies reduziert nicht nur die Arbeitslast der Agenten, sondern verhindert auch Performance-Einbußen durch übergeordnete “Sammel-Queues”.

---

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, Konvertierung von Prozessen (AI) und technischem Feintuning.

Starten Sie mit dem Wechsel auf Elasticsearch, führen Sie eine Archivierung ein und entlasten Sie Ihre Agenten mit OpenTicketAI. So bleibt Ihr OTOBO-System auch bei wachsender Unternehmensgröße reaktionsschnell und stabil.