OTOBO / Znuny – Prestatieoptimalisatie

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

1. Indexmodules voor ticketwachtrijen
2. Volledige tekst- en documentzoekopdrachten (intern & Elasticsearch)
3. Artikelopslagback-ends (DB vs. FS)
4. Ticketarchivering
5. Caching (Redis, Ramdisk)
6. Databaseafstemming (MySQL/MariaDB)
7. Hardware & Infrastructuur
8. Automatisering (Cron, Docker-Compose Scripts)
9. Monitoring & Alerts

1. Ticketindexmodule

1.1 RuntimeDB (Standaard)

• Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Werkingswijze: Dynamische queries rechtstreeks op ticket-tabel
• Toepassingsgebied: Tot ~60k open tickets zonder merkbare latentie
• Metrische gegevens: Query-tijd ∝ Ticketaantal ➔ lineaire toename

1.2 StaticDB (High-Scale)

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

• Werkingswijze: Vooraf gecompileerde ticket_index-tabel met tokenkolommen (Onderwerp, Status, Eigenaar enz.)

• Toepassingsgebied: >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 gedeeltelijke rebuilds alleen voor gewijzigde wachtrijen (SysConfig-optie)
  • Monitoring van de uitvoeringsduur: meten via time-opdracht

2. Volledige tekstzoekopdracht & Documentzoekopdracht

2.1 Interne volledige tekstindex

• Opdracht 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	Standaard	Regex-filter voor speciale tekens
  Ticket::SearchIndex::StopWords###Custom	nl, 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 gegevens (>10M artikelen) wordt Elasticsearch aanbevolen.

2.2.1 JVM-heapgrootte

# jvm.options
-Xms4g
-Xmx4g

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

2.2.2 Schijfwatermerken

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-toewijzing
• flood_stage zet indices read-only

2.2.3 Mapping-optimalisaties

• keyword-type voor zelden gewijzigde velden (bijv. Ticket-IDs)
• text + analyzer voor vrije tekst

3. Artikelopslagback-ends

Back-end	Opslaglocatie	Toepassing
DB	MySQL/MariaDB	< 10k bijlagen, single-server
FS	lokaal bestandssysteem / 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. Ticketarchivering

Vermindert actief geïndexeerde gegevenssets.

1. SysConfig: Ticket::ArchiveSystem = 1

2. GenericAgent-taak instellen:

   • Limiet: max. 5000 tickets per run
   • Filter: State = gesloten EN Gewijzigd < nu-6maanden

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

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria State:gesloten,Gewijzigd:-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
# /etc/fstab toevoegen:
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Databaseafstemming (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   # prestatie/OCR-balans
max_connections         = 500       # verwachte agenten+API
thread_cache_size       = 50        # hergebruik threads
query_cache_type        = 0         # uitgeschakeld (verouderd)

• Benchmark: TPC-C of sysbench voor belastingstests

7. Hardware & Infrastructuur

• CPU: ≥ 8 cores voor parallelle verwerking
• RAM: Voldoende voor DB-pool + JVM + caches
• Opslag: NVMe-SSD's in RAID10 (≥ 10k IOPS)
• Netwerk: 10 GbE tussen frontend & DB
• Load-balancer: HAProxy of NGINX met health-checks

8. Automatisering & Back-upscripts

8.1 Docker-Compose-back-up

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

#!/usr/bin/env bash
set -euo pipefail
DATUM=$(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_$DATUM.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATUM.sql"
# Starten
docker compose -f "$COMPOSE_FILE" up -d
echo "Back-up $DATUM voltooid"

Cron (uurlijks):

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

8.2 Opkuisen oude back-ups

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

Cron: dagelijks 1:00 uur

9. Monitoring & Alerts

• Prometheus Exporter: otobo-agent metrische gegevens (responstijd, wachtrijdiepte)

• Grafana-dashboard:

  • Querylatentie (95e percentiel)
  • Redis-cache-hits vs. misses
  • InnoDB-bufferpoolgebruik
  • Elasticsearch-shardstatus

• Alertregels:

  • Trage queries > 200 ms voor > 5 min
  • Schijfwatermerk > 90%
  • Heap-pauzes > 100 ms
  • DB-verbindingen > 80% van max_connections

Conclusie

Met deze uitgebreide prestatieoptimalisatieplan op index-, zoek-, opslag-, cache-, database- en infrastructuurniveau bereikt u in OTOBO/Znuny een stabiele en snelle platform die ook bij miljoenen tickets en artikelen soepel schaalt.