Skip to content
OTOBO Community Guide

OTOBO Performance Optimization – Scaling for High Ticket Volume

OTOBO Performance

In this guide: Keep OTOBO fast with high ticket volumes — indexing, caching, database, and infrastructure levers.

Related: System configuration · Backup · Version 11 · Hosting

A high-performance ticket system is the foundation for excellent support. OTOBO (especially from version 11) offers numerous levers to remain lightning-fast even with high ticket volumes (> 1 million articles).

[!TIP] Quick Win: Use a StaticDB ticket index and route incoming mail into focused queues instead of a single catch-all queue. That reduces dashboard load and keeps agents from manually triaging high-volume inboxes.

1. Ticket Index Modules

Section titled “1. Ticket Index Modules”

The index determines how quickly list views (Dashboard, Queue View) are loaded.

1.1 RuntimeDB (Standard for small instances)

Section titled “1.1 RuntimeDB (Standard for small instances)”
  • Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
  • Behavior: Queries are performed live on the ticket table.
  • Limit: Performant up to approx. 50,000 open tickets. Beyond that, the load increases noticeably with every dashboard refresh.
Section titled “1.2 StaticDB (Recommended for high-scale)”
  • Module: Kernel::System::Ticket::IndexAccelerator::StaticDB
  • Advantage: Uses a dedicated ticket_index table. Write operations are minimally slower, but read access (lists) is faster by factors and remains constant.
  • Setup:
    1. Change in the System Configuration.
    2. Build the initial index:
      Terminal window
      /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild

2. Search & Indexing (Elasticsearch)

Section titled “2. Search & Indexing (Elasticsearch)”

While the internal SQL index is sufficient for small quantities, there is no way around Elasticsearch for large datasets.

2.1 Elasticsearch Tuning (OTOBO Docker context)

Section titled “2.1 Elasticsearch Tuning (OTOBO Docker context)”

If you run OTOBO in Docker (recommended for installation), pay attention to the JVM settings in your docker-compose.override.yml:

services:
  elasticsearch:
    environment:
      - ES_JAVA_OPTS=-Xms4g -Xmx4g
  • Heap Size: Set the heap to a maximum of 50% of the available RAM (max. 31GB).
  • Disk Watermarks: Elasticsearch switches indices to read-only when disk space runs low (< 5% free). Monitoring is essential here.

2.2 Internal Full-Text Index (SQL)

Section titled “2.2 Internal Full-Text Index (SQL)”

If you do not use Elasticsearch, limit the scope:

  • WordCountMax: Limit to 500-1000 words (Ticket::SearchIndex::Attribute.WordCountMax).
  • Archived Tickets: Exclude these from the search index to keep the DB size compact.

3. Data Storage & Backends

Section titled “3. Data Storage & Backends”

3.1 Article Storage (FS vs. DB)

Section titled “3.1 Article Storage (FS vs. DB)”

By default, OTOBO stores attachments in the database (ArticleStorageDB).

  • From 10,000 tickets or large attachments: You must switch to ArticleStorageFS.
  • Advantage: The database remains small, and backups/dumps run significantly faster.
Terminal window
/opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

3.2 Ticket Archiving

Section titled “3.2 Ticket Archiving”

Archive closed tickets that are older than 6-12 months. Archived tickets are no longer indexed by default, which massively speeds up daily work.

4. Caching & Memory

Section titled “4. Caching & Memory”

4.1 Redis (Must-Have)

Section titled “4.1 Redis (Must-Have)”

Use Redis as a caching backend instead of the file system. Redis keeps configurations and sessions in RAM.

  • SysConfig: Set Cache::Module to Redis.
  • Expert Tip: Use Redis::Fast for even lower latencies in high-traffic environments.

4.2 Ramdisk for /opt/otobo/var/tmp

Section titled “4.2 Ramdisk for /opt/otobo/var/tmp”

If you are not using Docker, move the temp directory to RAM:

Terminal window
mount -t tmpfs -o size=4G tmpfs /opt/otobo/var/tmp

Accelerates the generation of PDF reports and temporary article files.

5. Database Tuning (MariaDB/MySQL)

Section titled “5. Database Tuning (MariaDB/MySQL)”

For OTOBO 11, we recommend the following parameters (with 16GB+ RAM):

[mysqld]
innodb_buffer_pool_size = 8G         # approx. 50-60% of RAM
innodb_log_file_size    = 1G          # important for performance during mass updates
innodb_flush_log_at_trx_commit = 2    # compromise between speed and data security
max_connections         = 500

[!IMPORTANT] OTOBO 11 uses more efficient queries but benefits extremely from fast I/O. Use exclusively NVMe-SSDs.

6. OTOBO 11 & Docker Specifics

Section titled “6. OTOBO 11 & Docker Specifics”

OTOBO 11 is natively optimized for Docker.

  • Container Images: The official images are already tuned for performance (Perl-level optimizations).
  • Log Rotation: From version 11.0.11, OTOBO has integrated log rotation for otobo.log. External scripts are no longer strictly necessary for this log file.
  • Auto-Tuning: The containers often detect available resources automatically; however, limits (mem_limit) should still be set in Docker Compose.

7. Monitoring & Early Detection

Section titled “7. Monitoring & Early Detection”

No optimization without data. We recommend the Prometheus stack:

  1. Metrics: Capture OTOBO metrics via API.
  2. Grafana: Dashboard for:
    • Request latency (SLA tracking)
    • Queue fill level (detect bottlenecks)
    • DB lock wait times
  3. Alerting: Notification if the cache hit rate falls below 90% or Elasticsearch shards turn “yellow”.

Conclusion

Section titled “Conclusion”

Performance optimization in OTOBO is an interplay of hardware, process design, and technical fine-tuning.

Start by switching to Elasticsearch, implement archiving, and keep catch-all queues lean. This way, your OTOBO system remains responsive and stable even as your company grows.

OTOBO Health Check & Performance Tuning

Is your OTOBO sluggish under load? We optimize database performance, caching, search indices, and background daemons.

Request health check

Frequently asked questions

How can I optimize OTOBO's ticket indexing for high ticket volumes, and what are the key differences between RuntimeDB and StaticDB?

For small OTOBO instances with up to approximately 50,000 open tickets, the default RuntimeDB module (Kernel::System::Ticket::IndexAccelerator::RuntimeDB) is sufficient. It performs live queries on the ticket table, but its performance degrades noticeably with higher volumes, especially during dashboard refreshes.

For high-scale environments with large ticket volumes, it is highly recommended to switch to StaticDB (Kernel::System::Ticket::IndexAccelerator::StaticDB). This module utilizes a dedicated ticket_index table, which significantly improves read access for lists (like the Dashboard and Queue View) by factors, keeping performance constant regardless of ticket growth. While write operations are minimally slower due to the index maintenance, the benefits for read-heavy operations are substantial. To set up StaticDB, you first change the module in the System Configuration, then build the initial index using the console command: /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild. This ensures your OTOBO system remains responsive and efficient as your ticket count grows.

Quellen / Sources

What role does Elasticsearch play in OTOBO's search performance, and how should it be configured for optimal results?

Elasticsearch is crucial for significantly boosting OTOBO's full-text search performance, especially when dealing with large datasets where the internal SQL index becomes insufficient. Proper configuration ensures fast and efficient searching across millions of articles.

When running OTOBO in a Docker environment, pay close attention to Elasticsearch's JVM settings in your docker-compose.override.yml. The ES_JAVA_OPTS environment variable allows you to set the heap size, for example: -Xms4g -Xmx4g. It's a best practice to allocate a maximum of 50% of the available RAM to the heap, with an absolute maximum of 31GB. Additionally, monitoring disk watermarks is vital; Elasticsearch can switch indices to read-only if disk space falls below a certain threshold (e.g., < 5% free), which can disrupt operations. If Elasticsearch is not used, you should limit the scope of the internal full-text SQL index by setting Ticket::SearchIndex::Attribute.WordCountMax to 500-1000 words and excluding archived tickets to keep the database compact.

Quellen / Sources

What are the best practices for OTOBO data storage and ticket archiving to maintain system performance with growing data?

For optimal performance, especially with 10,000 tickets or more, or when handling large attachments, it is essential to switch OTOBO's article storage from the default ArticleStorageDB (storing attachments in the database) to ArticleStorageFS (storing attachments on the file system). This change significantly reduces the database size, leading to faster backups, dumps, and overall database operations. The switch can be performed using the console command: /opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS.

Beyond storage, proactive ticket archiving is a critical performance lever. Regularly archive closed tickets that are older than 6-12 months. Archived tickets are typically excluded from the default search index, which massively speeds up daily operations for agents and reduces the load on the system. This practice keeps your active dataset lean and ensures that OTOBO remains responsive even as your historical data grows.

Quellen / Sources

How do caching mechanisms like Redis and Ramdisk contribute to OTOBO's performance and responsiveness?

Caching is a fundamental component for enhancing OTOBO's speed and responsiveness, particularly in high-traffic environments. Redis is a must-have caching backend that stores configurations and user sessions directly in RAM, drastically reducing the need for repeated database queries and file system access. To enable Redis, you configure Cache::Module to Redis in your System Configuration. For even lower latencies and improved throughput in very demanding setups, consider using Redis::Fast.

Another effective caching strategy, especially if you're not using Docker, involves utilizing a Ramdisk for the /opt/otobo/var/tmp directory. By mounting a temporary file system (tmpfs) in RAM (e.g., mount -t tmpfs -o size=4G tmpfs /opt/otobo/var/tmp), you accelerate operations that rely on temporary files, such as the generation of PDF reports and the handling of temporary article files. This minimizes I/O bottlenecks and contributes to a snappier user experience.

Quellen / Sources

What specific database tuning parameters are recommended for MariaDB/MySQL to optimize OTOBO 11's performance, especially with 16GB+ RAM?

For OTOBO 11, especially when running with 16GB or more RAM, optimizing your MariaDB/MySQL database is crucial for peak performance. The [mysqld] section of your database configuration should include several key parameters. Set innodb_buffer_pool_size to approximately 50-60% of your available RAM (e.g., 8G for a 16GB system) to cache frequently accessed data. The innodb_log_file_size should be set to 1G (or higher) as it significantly impacts performance during mass updates. For a balance between speed and data security, innodb_flush_log_at_trx_commit can be set to 2. Finally, increase max_connections to 500 to accommodate a higher number of concurrent OTOBO processes.

It's important to note that OTOBO 11 features more efficient queries, but its performance benefits immensely from fast I/O. Therefore, using exclusively NVMe-SSDs for your database storage is highly recommended to eliminate I/O bottlenecks and ensure rapid data access.

Quellen / Sources

How does OTOBO 11 leverage Docker for performance, and what specific Docker-related configurations should be considered?

OTOBO 11 is natively optimized for Docker, offering several built-in performance advantages. The official container images are pre-tuned with Perl-level optimizations, ensuring efficient resource utilization right out of the box. This makes Docker the recommended environment for OTOBO installations, as it simplifies deployment and scaling while maintaining high performance.

From version 11.0.11 onwards, OTOBO includes integrated log rotation for otobo.log, reducing the need for external log management scripts and simplifying maintenance. While OTOBO containers often detect available resources automatically, it's still crucial to explicitly set resource limits, such as mem_limit, in your Docker Compose file. This prevents containers from consuming excessive host resources and ensures system stability. Scaling web and daemon services within Docker, combined with robust caching and database tuning, is an effective strategy to handle higher ticket volumes and improve overall system throughput.

Quellen / Sources