Znuny – Performance Optimization

Znuny – Performance Optimization

In this in-depth guide, we cover all relevant layers for a scalable and high-performance Znuny installation:

1. Index modules for ticket queues
2. Full-text and document search (internal & Elasticsearch)
3. Article storage backends (DB vs. FS)
4. Ticket archiving
5. Caching (Redis, Ramdisk)
6. Database tuning (MySQL/MariaDB)
7. Hardware & infrastructure
8. Automation (Cron, Docker-Compose scripts)
9. Monitoring & alerts

1. Ticket Index Module

1.1 RuntimeDB (Standard)

• Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Functionality: Dynamic queries directly on the ticket table
• Use case: Up to ~60k open tickets without noticeable latency
• Metric: Query-Time ∝ Number of tickets ➔ linear increase

1.2 StaticDB (High-Scale)

• Module: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Functionality: Precompiled ticket_index table with token columns (subject, status, owner, etc.)
• Use case: >80k open tickets, constant query times
• Initial indexing: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Cron example: Daily rebuild at 02:30 AM ticket
• Optimization tips:
  • Automatic partial rebuilds only for changed queues (SysConfig option)
  • Monitoring runtime: measure via time command

2. Full-Text Search & Document Search

2.1 Internal Full-Text Index

• Command for rebuild: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Recommended SysConfig:

  Setting	Value	Purpose
  Ticket::SearchIndex::IndexArchivedTickets	0 (off)	Exclude archived tickets
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Index first 1000 words
  Ticket::SearchIndex::Filters	Standard	Regex filter for special chars
  Ticket::SearchIndex::StopWords###Custom	de, en	Add custom stopwords

• Example filter (SysConfig under Filters): ticket_index

2.2 Elasticsearch (optional)

For large data volumes (>10M articles), Elasticsearch is recommended.

2.2.1 JVM Heap Size

time

• Set Min = Max to minimize GC pauses
• Max ≤ 50% of physical RAM

2.2.2 Disk Watermarks

keyword

• low/high for shard allocation
• flood_stage sets indices to read-only

2.2.3 Mapping Optimizations

• keyword type for rarely changed fields (e.g., ticket IDs)
• text + analyzer for free text

3. Article Storage Backends

Backend	Storage Location	Use Case
DB	MySQL/MariaDB	< 10k attachments, single-server
FS	local FS / NFS / SAN	≥ 10k attachments, multi-server, high IOPS

3.1 Switching DB ↔ FS

text

• Check /opt/znuny/var/log/article_storage.log
• Pay attention to permissions: user znuny (UID 1000)

4. Ticket Archiving

Actively reduces indexed data records.

1. SysConfig: Ticket::ArchiveSystem = 1
2. Set up GenericAgent job:
   • Limit: max. 5000 tickets per run
   • Filter: State = close AND Changed < now-6mon
3. Cron (weekly Mon 4:00 AM): analyzer

5. Caching

5.1 Redis Cache

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

5.2 Ramdisk for /opt/znuny/var/tmp

Ticket::ArchiveSystem = 1

6. Database Tuning (MySQL/MariaDB)

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

• Benchmark: TPC-C or sysbench for load testing

7. Hardware & Infrastructure

• CPU: ≥ 8 cores for parallelism
• RAM: Sufficient for DB pool + JVM + caches
• Storage: NVMe-SSDs in RAID10 (≥ 10k IOPS)
• Network: 10 GbE between frontend & DB
• Load-Balancer: HAProxy or NGINX with health checks

8. Automation & Monitoring Scripts

8.1 Performance Monitoring

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

8.2 Cleaning up old logs

/opt/znuny/var/tmp Cron: daily 1:00 AM

9. Monitoring & Alerts

• Prometheus Exporter: znuny-agent metrics (ResponseTime, QueueDepth)
• Grafana Dashboard:
  • Query latency (95th percentile)
  • Redis cache hits vs. misses
  • InnoDB Buffer Pool usage
  • Elasticsearch shard status
• Alert Rules:
  • Slow queries > 200 ms for > 5 min
  • Disk watermark > 90%
  • Heap pauses > 100 ms
  • DB connections > 80% of max_connections

Conclusion

With this comprehensive performance tuning plan covering index, search, storage, cache, database, and infrastructure layers, you will achieve a stable and fast platform in Znuny that scales smoothly even with millions of tickets and articles.