Application Delivery Management
Application Modernization & Connectivity
IT Operations Management
CyberRes
While executing the examples in previous articles, did you notice that the worker threads created by the Server to service the requests are still present (for quite some time) even after all the requests have been serviced? Is there any way to destroy these idling threads sooner so as to conserve thread resources?
Yes. You can tune the Thread Pool Dispatcher “vbroker.se.<se_name>.scm.<scm_name>.dispatcher.threadMaxIdle” property to accomplish it.
The "echo_service_cpp" example is used in this demonstration.
Can you guess exactly how long it will take before the idling worker threads are destroyed?
Configure the Client by modifying c.sh:
Configure the Server by modifying s.sh:
Make sure you have set up the necessary VisiBroker environment and build the example before running this demonstration.
MEMORY(KB) THREADS SOCKETS
15904 205 1
vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle=15
MEMORY(KB) THREADS SOCKETS
12856 4 1
Compare the resource consumption measurement of the idle Server before and after tuning “vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle=15” property at the Server side.
Server Memory (KB) | Server Threads | Server Sockets | |
Before Tuning | 15904 | 205 | 1 |
After Tuning | 12856 | 4 | 1 |
Key observations after tuning:
The default value for the “threadMaxIdle” property is 300 seconds. Reducing it to 15 seconds causes the idling worker threads to be destroyed by the Thread Pool earlier. On close observation, you may notice that the idle worker threads are destroyed slightly later than the “threadMaxIdle” time. This is expected because the Thread Pool mechanism takes some time to verify and destroy the idle worker threads.
For VBJ, there is an internal garbage collector thread which periodically clean up expired resources (e.g. idle threads and connections). The "vbroker.orb.gcTimeout" property control the period this garbage collector thread wakes up to perform the work. The default timeout value is 30 seconds. This timeout setting can influence the time lag which an idle worker thread is destroyed.
Destroying idle threads can help to conserve the process's shared thread resources, so that other modules in the same process can also use it.
On the other hand, an unreasonably small “threadMaxIdle” value (e.g. a few seconds) is also not recommended. It will result in frequent destruction and creation of worker threads, instead of reusing the idle worker threads found in the Thread Pool. Frequent thread creations and destructions can affect performance because such operations are relatively expensive for most operating systems.
So what is the best value for "theadMaxIdle"? You need to perform some benchmark tests to find the optimal “threadMaxIdle” value that is suitable to your application.
Although this demonstration is based on a VBC example, the "threadMaxIdle" property is also applicable to VBJ too.
You have learnt how the Thread Pool Dispatcher can be tuned to destroy idle worker threads earlier to conserve the process's thread resources.