description: > Uitgebreide technieken en best practices voor het optimaliseren van de prestaties van uw OTOBO- en Znuny-installatie: configuratie, indexen, opslagmodules, caching, database- en hardware-tuning, automatisering en monitoring.

OTOBO / Znuny – Prestatieoptimalisatie

In deze diepgaande gids behandelen we alle relevante niveaus voor een schaalbare en performante OTOBO- of Znuny-installatie:

1. Indexmodules voor Ticketwachtrijen
2. Full-text en Document Zoeken (intern & Elasticsearch)
3. Artikelopslag Backends (DB vs. FS)
4. Ticket Archivering
5. Caching (Redis, Ramdisk)
6. Database Tuning (MySQL/MariaDB)
7. Hardware & Infrastructuur
8. Automatisering (Cron, Docker-Compose Scripts)
9. Monitoring & Alerts

1. Ticket Index Module

1.1 RuntimeDB (Standaard)

• Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Functionaliteit: Dynamische queries direct op de ticket-tabel
• Gebruiksscenario: Tot ~60k open tickets zonder merkbare latentie
• Metriek: Query-tijd ∝ Aantal tickets ➔ lineaire stijging

1.2 StaticDB (High-Scale)

• Module: Kernel::System::Ticket::IndexAccelerator::StaticDB

• Functionaliteit: Vooraf gecompileerde ticket_index-tabel met token-kolommen (onderwerp, status, eigenaar, enz.)

• Gebruiksscenario: >80k open tickets, constante querytijden

• Initiële Indexering:

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

• Cron-voorbeeld: Dagelijkse rebuild om 02:30 uur

  30 2 * * * /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild --force >> /var/log/otobo/queueindex.log 2>&1

• Optimalisatietips:

  • Automatische deel-rebuilds alleen voor gewijzigde wachtrijen (SysConfig-optie)
  • Monitoring van de looptijd: meten via time-commando

2. Full-text & Document Zoeken

2.1 Interne Full-text Index

• Commando voor Rebuild:

  /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild

• Aanbevolen SysConfig:

  Instelling	Waarde	Doel
  Ticket::SearchIndex::IndexArchivedTickets	0 (uit)	Gearchiveerde tickets uitsluiten
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Eerste 1000 woorden indexeren
  Ticket::SearchIndex::Filters	Standard	Regex-filters voor speciale tekens
  Ticket::SearchIndex::StopWords###Custom	de, en	Eigen stopwoorden toevoegen

• Voorbeeld-filter (SysConfig onder Filters):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Speciale tekens verwijderen
  s#\b\S{1,2}\b##g                       # Woorden <3 tekens verwijderen

2.2 Elasticsearch (optioneel)

Voor grote hoeveelheden data (>10M artikelen) wordt Elasticsearch aanbevolen.

2.2.1 JVM Heap Grootte

# jvm.options
-Xms4g
-Xmx4g

• Stel Min = Max in om GC-pauzes te minimaliseren
• Max ≤ 50% van de fysieke RAM

2.2.2 Disk Watermarks

cluster.routing.allocation.disk.watermark.low: "85%"
cluster.routing.allocation.disk.watermark.high: "90%"
cluster.routing.allocation.disk.watermark.flood_stage: "95%"

• low/high voor shard-allocatie
• flood_stage zet indexen op read-only

2.2.3 Mapping Optimalisaties

• keyword-type voor zelden gewijzigde velden (bv. Ticket-ID's)
• text + analyzer voor vrije tekst

3. Artikelopslag Backends

Backend	Opslaglocatie	Gebruik
DB	MySQL/MariaDB	< 10k bijlagen, enkele server
FS	lokaal FS / NFS / SAN	≥ 10k bijlagen, multi-server, hoge IOPS

3.1 Wisselen DB ↔ FS

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

• Controleer /opt/otobo/var/log/article_storage.log
• Let op machtigingen: gebruiker otobo (UID 1000)

4. Ticket Archivering

Vermindert actief geïndexeerde records.

1. SysConfig: Ticket::ArchiveSystem = 1

2. GenericAgent-taak instellen:

   • Limiet: max. 5000 tickets per run
   • Filter: State = close EN Changed < now-6mon

3. Cron (wekelijks ma 4:00 uur):

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria State:close,Changed:-6m >> /var/log/otobo/archive.log

5. Caching

5.1 Redis Cache

1. Installatie:

   yum install redis
   systemctl enable --now redis

2. Perl-module: cpan install Redis::Fast

3. SysConfig:

   Cache::Module: Redis
   Cache::Redis###Server: 127.0.0.1:6379
   Cache::Redis###DatabaseNumber: 0
   Cache::Redis###RedisFast: 1

5.2 Ramdisk voor /opt/otobo/var/tmp

mount -t tmpfs -o size=8G tmpfs /opt/otobo/var/tmp
# Toevoegen aan /etc/fstab:
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Database Tuning (MySQL/MariaDB)

Bewerk /etc/my.cnf.d/otobo.cnf:

[mysqld]
innodb_buffer_pool_size = 12G        # 60% van 20G RAM
innodb_log_file_size    = 1G         # grote transacties
innodb_flush_log_at_trx_commit = 2   # Performance/OCR-balans
max_connections         = 500       # verwachte agents+API
thread_cache_size       = 50        # hergebruik threads
query_cache_type        = 0         # uitgeschakeld (deprecated)

• Benchmark: TPC-C of sysbench voor load tests

7. Hardware & Infrastructuur

• CPU: ≥ 8 Cores voor parallellisme
• RAM: Voldoende voor DB pool + JVM + caches
• Storage: NVMe SSDs in RAID10 (≥ 10k IOPS)
• Netwerk: 10 GbE tussen frontend & DB
• Load-balancer: HAProxy of NGINX met health checks

8. Automatisering & Backup Scripts

8.1 Docker-Compose Backup

Script: /usr/local/bin/otobo_backup.sh

#!/usr/bin/env bash
set -euo pipefail
DATE=$(date +"%Y%m%d_%H%M%S")
COMPOSE_FILE=/opt/otobo-docker/compose.yml
# Stoppen voor consistentie
docker compose -f "$COMPOSE_FILE" down
# Volumes & DB-dump
tar -czf "/backups/volumes_$DATE.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATE.sql"
# Starten
docker compose -f "$COMPOSE_FILE" up -d
echo "Backup $DATE voltooid"

Cron (uurlijks):

0 * * * * /usr/local/bin/otobo_backup.sh >> /var/log/otobo/backup.log 2>&1

8.2 Oude Backups Opruimen

#!/usr/bin/env bash
find /backups -type f -mtime +7 -delete

Cron: dagelijks 1:00 uur

9. Monitoring & Alerts

• Prometheus Exporter: otobo-agent metrics (ResponseTime, QueueDepth)

• Grafana Dashboard:

  • Query latentie (95e percentiel)
  • Redis cache hits vs. misses
  • InnoDB buffer pool gebruik
  • Elasticsearch shard status

• Alert Rules:

  • Trage queries > 200 ms voor > 5 min
  • Disk watermark > 90%
  • Heap pauzes > 100 ms
  • DB connecties > 80% van max_connections

Conclusie

Met dit uitgebreide prestatie-tuningplan op index-, zoek-, opslag-, cache-, database- en infrastructuurniveau bereikt u in OTOBO/Znuny een stabiel en snel platform dat soepel schaalt, zelfs bij miljoenen tickets en artikelen.