Other Thread Pool Dispatcher Tuning



The last few articles use practical examples to demonstrate and explain some common Thread Pool Dispatcher properties which you can tune. In this article, we will briefly discuss a few other properties.


The "vbroker.se.<se_name>.scm.<scm_name>.dispatcher.threadMin" property sets the minimum number of worker threads maintained by the Thread Pool, even when no request needs to be serviced. The thread garbage collection mechanism will make sure that the "threadMin" setting is adhered to, before destroying the idle worker threads (due to "threadMaxIdle"). The number of worker threads specified by "threadMin" are  also created when the Thread Pool is first initialized. The default value for "threadMin" is 0, which means no minimum number of thread is maintained in the Thread Pool.

Keeping some idle threads in the pool may help to improve performance. This is because reusing existing threads is faster than the creation of new threads, which is a relatively slow and expensive operation.

Both VBC and VBJ has similar feature.


The "vbroker.se.<se_name>.scm.<scm_name>.dispatcher.coolingTime" property sets the duration (in seconds) by which a worker thread waits for new requests from a "hot" connection. A connection is considered "hot" if it is just created, or has just received a request. The worker thread will wait for new requests to arrive from this connection for a time interval specified by "coolingTime". If no request arrives within this period, the worker thread is returned back to the Thread Pool, and the connection is also returned back to the Server Engine Listener.

This feature may improve performance if new requests are arriving frequently from the same connection within the "coolingTime" period. But if this is not the case, you may be just wasting thread resources waiting on inactive connections. So you should not set a large value for this property. In fact, the maximum value you can set is only 10 seconds. It's default value for VBC is 3 seconds.

Note that this property is only applicable to VBJ when Java NIO based dispatcher is used (i.e. by setting "vbroker.se.<se_name>.scm.<scm_name>.manager.type=Socket_nio"). The default value for VBJ is 0. This means that a connection ceases to be “hot” unless a new request is immediately available. It's maximum value is also 10 seconds.

Similar to the other tuning properties, you need to perform some benchmark tests to find the optimal value that can deliver the best performance and stability. A large value may even lead to worse performance.


The "vbroker.se.<se_name>.scm.<scm_name>.dispatcher.threadStackSize" property sets the stack size of the worker thread. The default value of 0 indicates that the system default size is used. Each operating system and platform defines it's own default size. This property is only applicable to VBC .

If stack overflow errors occur while the worker thread is servicing a complex request which requires large stack memory, you may need to increase it's value. On the other hand, if you need many worker threads to service many concurrent simple requests which require minimum stack memory, you may need to reduce it's value. You need to perform some tests to find the optimal "threadStackSize" value that is suitable to your application's stack memory requirement.

To control the stack size of the other VBC internal threads (i.e. those threads not managed by the Thread Pool), the "vbroker.orb.defaultThreadStackSize" property can be used. The default value of 0 indicates that the system default size is used.

Note that these two properties are not applicable to VBJ. But a similar JVM property "-Xss" can be used to set the thread stack size. The default value varies among the different JVMs from different platforms.

So far, you have learnt about the Thread Pool Dispatcher tuning properties that can help you achieve better performance and a more stable application. In general, to find the optimal configurations, you need to have a good understanding of your application/system and run performance/stability tests with different configurations.

In the next few articles, we will discuss about VisiBroker connection management and some of the properties which you can tune.

Back  |  Next


How To-Best Practice
Comment List
Related Discussions