This section explains the impact of different parameters in the <MB_HOME>/repository/conf/broker.xml file on the rate at which messages are published by publishers, as well as the rate at which the messages are consumed by the subscribers.
| Improvement Area | Description | Performance Recommendations |
|---|
| Reading messages from database and allocation of slots to consumers. See slots in the broker.xml file. | The windowSize parameter specifies the size of a slot. A publisher returns its last message ID to the slot manager each time he/she publishes a number of messages equal to the number specified in this parameter. The workerThreadCount parameter specifies the number of slots which should be initialized when WSO2 MB is started. The maxSubmitDelay parameter specifies the time interval in which, broker checks for slots that can be marked as 'ready to deliver' (i.e. slots that age more than the time specified in messageAccumulationTimeout). The nodes, which will have subscribers for a given queue/topic will periodically poll for slots during this interval. | Increasing the window size would increase the number of messages received per consumer. Thus the subscribers who are the earliest to be allocated slots would receive a higher number of messages. A lower window size would result in an even load of messages received by each subscriber. The default/recommended value is 1000. A higher worker thread count would result in a higher rate of message consumption, as well as a higher system overhead. Increase the thread count only if you have sufficient hardware resources. If the consumers are slow, then increasing the maxSubmitDelay would result in reduced CPU and I/O overhead on the DB. If the consumers are fast, there will be an increase in latency. |
| Message Delivery: This is the phase where messages read from the database are delivered to consumers. | The maxNumberOfReadButUndeliveredMessages parameter specifies the maximum number of messages undelivered messages that are allowed to be retained in the memory. The ringBufferSize parameter specifies the thread pool size of the queue delivery workers. The parallelContentReaders parameter specifies the number of parallel readers used to read content from the message store. The parallelDeliveryHandlers parameter specifies the number of parallel delivery handlers used to deliver messages to subscribers. The contentReadBatchSize parameter specifies the number of messages included in the content retrieval query. | The default value for the maxNumberOfReadButUndeliveredMessages parameter is 1000. Increasing this value can cause out-of-memory exceptions, but performance will be improved because the number of database calls will be reduced. Therefore, your allocated server memory capacity should be considered when configuring this parameter. The default value of 4096 for the ringBufferSize parameter can be increased if there are a lot of unique queues in the system. An increased ring buffer size is also required if the slot window size is large and therefore, there is a large number of messages to be delivered. The default value for both the parallelContentReaders parameter and the parallelDeliveryHandlers parameter is 5. Increasing this value would increase the speed of the message sending mechanism, however, the load on the message store would also be increased. A higher number of cores is required to increase these values. The contentReadBatchSize parameter is used to minimise the number of I/O operations. When large messages (i.e. larger than 1MB) are exchanged, the batch size should be reduced to avoid network latency. |
| Acknowledgement Handling: This is the phase where the delivery of messages that have reached the consumers is acknowledged. | The ackHandlerCount parameter specifies the number of message acknowledgement handlers to process acknowledgements concurrently. The ackHandlerBatchSize parameter specifies the maximum number of acknowledgements that can be handled by an acknowledgement handler. The message delivery from the MB server to the client will be temporarily paused if the number of messages of which the delivery is not acknowledged reaches the number specified for the maxUnckedMessages parameter. | The default value of 1 for the  ackHandlerCount parameter should be increased in a high throughput scenario with a relatively high amount of messages being delivered to the consumers. The value for this parameter can be decreased when the value specified for the  ackHandlerBatchSize parameter is high and as a result, each individual acknowledgement handler can handle a higher number of acknowledgements. Note that increasing the number of acknowledgement handlers when the number of messages being delivered and acknowledged is low, or when the value specified for the ackHandlerBatchSize parameter is high can result in idle acknowledgement handlers incurring an unnecessary system overhead. The default value of 100 for the ackHandlerBatchSize parameter should be increased when there is an increase in the number of messages being delivered to consumers. If the number of acknowledgements that can be handled by each individual acknowledgement handler is too low in a high throughput scenario, it will be required to increase the number of acknowledgement handlers. This would increase the number of calls made to the database, thereby increasing the system overhead. Increasing the value specified for the maxUnckedMessages parameter can cause out-of-memory exceptions, but the performance will be improved due to the the reduction in the number of calls to the database. Therefore, your allocated server memory capacity should be considered when configuring this parameter. |
| Content Handling: Handling incoming content chunks. | The contentChunkHandlerCount parameter specifies the number of handlers that should be available to handle content chunks concurrently. The maxContentChunkSize parameter specifies the maximum column size of a content chunk handler. | The default value of 3 for the contentChunkHandlerCount parameter should be increased when there is a significant number of large messages being published. A low value can be specified when the value for the maxContentChunkSize parameter is high in such situations, each individual handler will be able to handle a higher amount of content chunks. Note that increasing this value in a scenario where there are not many large messages published or when the maximum content chunk size is high can result in idle handlers causing an unnecessary system overhead. The default value of 65500 for the maxContentChunkSize parameter should be increased if there is an increased number of large messages being published. If the value specified for this parameter is too low, the value for the contentChunkHandlerCount parameter will have to be increased. This would increase the system overhead due to an increased number of calls made to the database. |
| Inbound Events: These are messaging events relating to publishers | The bufferSize parameter specifies the size of the Disruptor ring buffer for inbound event handling. The parallelMessageWriters parameter specifies the number of parallel writers used to write content to the message store. The messageWriterBatchSize parameter specifies the maximum batch size of the batch write operation for inbound messages. The purgedCountTimeout parameter specifies the number of milliseconds to wait for a queue to complete a purge event in order to update the purge count. If the time specified here elapses before the queue completes the purge event, the purge count will not be updated to include the event. | It is recommended to increase the value for the bufferSize parameter when there is an increase in the rate of publishing. The default/recommended value is 65536. Increasing the value for the parallelMessageWriters parameter increases the speed of the message receiving mechanism. However, it would also increase the load on the data store. A higher number of cores are required to increase this value. The default/recommended value is 1. The messageWriterBatchSize parameter should be used in high throughput scenarios to avoid database requests with a high load. A higher number of cores are required to increase this value. The default/recommended value is 70. The value for the purgedCountTimeout parameter can be increased to ensure that the purge count is accurate. |
| Failover | The vHostSyncTaskInterval parameter specifies the time interval after which the virtual host syncing task can sync host details across the cluster. | This interval should be reduced if frequent failures occur in the system. Reducing this interval to make more frequent checks in situations when there are not many fail overs would result in an unnecessary increase in the system overhead. The default/recommended value is 3600. |
| Message Counter: This is used by the management console to display the number of messages in a queue. | The counterTaskInterval parameter specifies the delay which should occur between the end of one execution and the start of another, in milliseconds. | Reducing the counter task interval would result in more database calls (in non RDBMS databases, this could be a very costly operation). The default/recommended value is 5 milliseconds. |
| Message Deletion | The contentRemovalTaskInterval parameter specifies the ask interval for the content removal task which will remove the actual message content from the store in the background. | If the publish/consumer rate is very high, a low value should be entered for the contentRemovalTaskInterval parameter to increase the number of delete requests per task.
|