Performance hints

This page offers several hints for performance tuning which would be good to keep in mind:

OpenHub = Apache Camel

There are many resources (articles, comments in discussions, etc.) which are related to Apache Camel performance issues.

List of interesting ones:

Database connection

OpenHub uses database for saving messages and their states (cross several nodes in the cluster):

  • use DB pooler, for example HikariCP (we have very good experience with it)
  • DB configuration is via Spring Boot "spring.datasource" properties, see Spring Boot documentation - direct database connection or via JNDI


SEDA configuration

Crucial component for processing incoming requests is SEDA component.

There are several points for keeping in mind:

  • we use the following configuration (see org.openhubframework.openhub.core.common.asynch.AsynchMessageRoute#URI_ASYNC_PROCESSING_MSG)
    • ASYNCH_CONCURRENT_CONSUMERS corresponds to the parameter ohf.asynch.concurrentConsumers, see OpenHub configuration
    • PRIORITY_QUEUE_FACTORY refers to Spring bean with the name "priorityQueueFactory"
  • default value of size or queueSize (maximum capacity of the SEDA queue i.e., the number of messages it can hold) is Integer.MAX_VALUE 
  • queue size must be big enough for saving incoming requests otherwise thread that adds new message will wait
  • SEDA uses PriorityBlockingQueueFactory (not default LinkedBlockingQueue implementation)
    • queue is sorted (see org.openhubframework.openhub.core.common.asynch.msg.MsgPriorityComparator) by processing priority attribute defined at Message object. 
    • incoming (new) requests have higher priority than re-processing messages 
  • watch logs and search for the following log message that give information how long the incoming message waits in SEDA queue for processing. If the time is high then it means that message waits too long in the queue for further processing => increase queue size or number of consumers (see ohf.asynch.concurrentConsumers)
  • Sometimes can happen when message is long time in queue that repairing process converts message back to PARTLY_FAILED state and evenly message can start with duplicate processing. In this case the following log message occurres:
    • repairing process is configured mainly by these two parameters -  ohf.asynch.repairRepeatTimeSec and ohf.asynch.partlyFailedIntervalSec

Thread pools

  • see threading model in Apache Camel or threading model in JBoss FUSE (note: JBoss FUSE is enterprise version of Apache Camel with better documentation)
  • see Design Notes for ThreadPool Configuration
  • default ThreadPoolProfile is as follows (defined in org.apache.camel.impl.DefaultExecutorServiceManager):
    • pool size - threads to keep minimum in pool
    • max pool size - the maximum pool size
    • max queue size - the maximum number of tasks in the work queue
  • we have small changes in our custom configuration (see org.openhubframework.openhub.core.config.CamelConfig)
    • MAX_THREAD_POOL_SIZE = 30

Throttling

Throttling can be disabled: ohf.disable.throttling = false

Caching

Use Cache / memory-grid functionality to increase performance when often data reading is necessary.