Znuny – Optimisation des performances

Znuny – Optimisation des performances

Dans ce guide approfondi, nous couvrons tous les niveaux pertinents pour une installation Znuny performante et évolutive :

1. Modules d’index pour les files d’attente de tickets
2. Recherche plein texte et recherche de documents (interne & Elasticsearch)
3. Backends de stockage d’articles (DB vs. FS)
4. Archivage de tickets
5. Caching (Redis, Ramdisk)
6. Tuning de la base de données (MySQL/MariaDB)
7. Matériel & Infrastructure
8. Automatisation (Cron, scripts Docker-Compose)
9. Monitoring & Alertes

1. Module d’index de tickets

1.1 RuntimeDB (Standard)

• Module : Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Fonctionnement : Requêtes dynamiques directement sur la table ticket
• Domaine d’application : Jusqu’à ~60k tickets ouverts sans latence perceptible
• Métrique : Temps de requête ∝ nombre de tickets ➔ augmentation linéaire

1.2 StaticDB (High-Scale)

• Module : Kernel::System::Ticket::IndexAccelerator::StaticDB
• Fonctionnement : Table ticket_index précompilée avec colonnes de jetons (objet, statut, propriétaire, etc.)
• Domaine d’application : >80k tickets ouverts, temps de requête constants
• Indexation initiale : Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Exemple Cron : Rebuild quotidien à 02h30 ticket
• Conseils d’optimisation :
  • Rebuilds partiels automatiques uniquement pour les files d’attente modifiées (option SysConfig)
  • Monitoring de la durée d’exécution : mesurer via la commande time

2. Recherche plein texte & recherche de documents

2.1 Index plein texte interne

• Commande pour le rebuild : Kernel::System::Ticket::IndexAccelerator::StaticDB
• SysConfig recommandée :

  Paramètre	Valeur	Objectif
  Ticket::SearchIndex::IndexArchivedTickets	0 (off)	Exclure les tickets archivés
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexer les 1000 premiers mots
  Ticket::SearchIndex::Filters	Standard	Filtre Regex pour caractères spéciaux
  Ticket::SearchIndex::StopWords###Custom	de, en	Ajouter des mots vides (stopwords) personnalisés

• Exemple de filtre (SysConfig sous Filters) : ticket_index

2.2 Elasticsearch (optionnel)

Pour de grands volumes de données (>10M d’articles), Elasticsearch est recommandé.

2.2.1 Taille du tas JVM (Heap Size)

time

• Définir Min = Max pour minimiser les pauses GC
• Max ≤ 50% de la RAM physique

2.2.2 Filigranes de disque (Disk Watermarks)

keyword

• low/high pour l’allocation des shards
• flood_stage rend les index en lecture seule

2.2.3 Optimisations de mapping

• Type keyword pour les champs rarement modifiés (ex: IDs de tickets)
• text + analyzer pour le texte libre

3. Backends de stockage d’articles

Backend	Emplacement de stockage	Utilisation
DB	MySQL/MariaDB	< 10k pièces jointes, serveur unique
FS	FS local / NFS / SAN	≥ 10k pièces jointes, multi-serveur, IOPS élevés

3.1 Changement DB ↔ FS

text

• Vérifier /opt/znuny/var/log/article_storage.log
• Attention aux permissions : utilisateur znuny (UID 1000)

4. Archivage de tickets

Réduit activement les jeux de données indexés.

1. SysConfig : Ticket::ArchiveSystem = 1
2. Configurer un job GenericAgent :
   • Limite : max. 5000 tickets par exécution
   • Filtre : State = close ET Changed < now-6mon
3. Cron (hebdomadaire lun 4h00) : analyzer

5. Caching

5.1 Cache Redis

1. Installation : /opt/znuny/var/log/article_storage.log
2. Module Perl : cpan install Redis::Fast
3. SysConfig : znuny

5.2 Ramdisk pour /opt/znuny/var/tmp

Ticket::ArchiveSystem = 1

6. Tuning de la base de données (MySQL/MariaDB)

Modifier /etc/my.cnf.d/znuny.cnf : State = close

• Benchmark : TPC-C ou sysbench pour les tests de charge

7. Matériel & Infrastructure

• CPU : ≥ 8 cœurs pour la parallélisation
• RAM : Suffisante pour le pool DB + JVM + caches
• Stockage : SSD NVMe en RAID10 (≥ 10k IOPS)
• Réseau : 10 GbE entre le Frontend et la DB
• Load-Balancer : HAProxy ou NGINX avec health-checks

8. Automatisation & Scripts de monitoring

8.1 Monitoring des performances

Script : /usr/local/bin/znuny_monitor.sh Changed < now-6mon Cron (toutes les heures) : cpan install Redis::Fast

8.2 Nettoyage des anciens logs

/opt/znuny/var/tmp Cron : quotidien à 1h00

9. Monitoring & Alertes

• Prometheus Exporter : Métriques znuny-agent (ResponseTime, QueueDepth)
• Tableau de bord Grafana :
  • Latence des requêtes (95e percentile)
  • Hits vs Misses du cache Redis
  • Utilisation du buffer pool InnoDB
  • État des shards Elasticsearch
• Règles d’alerte :
  • Requêtes lentes > 200 ms pendant > 5 min
  • Filigrane disque > 90%
  • Pauses Heap > 100 ms
  • Connexions DB > 80% de max_connections

Conclusion

Grâce à ce plan complet d’optimisation des performances au niveau des index, de la recherche, du stockage, du cache, de la base de données et de l’infrastructure, vous obtiendrez une plateforme Znuny stable et rapide, capable d’évoluer sans problème même avec des millions de tickets et d’articles.