OTOBO Performance-Optimierung – Skalierung bei hohem Ticketvolumen

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

Aktivieren Sie den StaticDB-Ticketindex, optimieren Sie Caching (z. B. Redis) und prüfen Sie Datenbankindizes unter Last.

Q: Hilft Elasticsearch bei der OTOBO-Suche?

Ja. Eine saubere Elasticsearch-Konfiguration kann die Volltextsuche bei großem Ticketvolumen deutlich beschleunigen.

Q: Kann Docker-Skalierung den Durchsatz erhöhen?

Ja. Die Skalierung von Web- und Daemon-Services zusammen mit Caching und Datenbank-Tuning hilft bei höherem Ticketvolumen.

OTOBO Performance

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:
  Terminal-Fenster
```
/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:

Metrics: Abgreifen der OTOBO Metriken via API.
Grafana: Dashboard für:
- Request-Latenz (SLA Tracking)
- Queue-Füllstand (Engpässe erkennen)
- DB-Lock-Wait-Times
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.

Häufig gestellte Fragen

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