Back

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.

Scenario

• The Client creates 200 threads to call 1 Server concurrently.
• Each client thread calls the Server once.
• Each invocation blocks for 10 seconds at the Server side.
• “threadMax=500” is set at Server side
• Monitor the Server's resource consumption of the idle Server after all the invocations have completed.
• Observe the effect of setting "threadMaxIdle=15".

Can you guess exactly how long it will take before the idling worker threads are destroyed?

Preparation

Configure the Client by modifying c.sh:

• Set the following properties:
  • server_sleep_time 10
  • vbroker.agent.enableLocator=false
• Disable all the other properties.

Configure the Server by modifying s.sh:

• Set the following properties:
  • vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax=500
  • vbroker.agent.enableLocator=false
  • vbroker.se.default.local.manager.enabled=false
• Disable all the other properties.

Execution

Make sure you have set up the necessary VisiBroker environment and build the example before running this demonstration.

• Start the Server Monitor script:
  • mon_s.sh
• Start the Server:
  • s.sh 1
• Start the Client:
  • c.sh 1 1 200
• After the Client has completed all the invocations, wait for some time (about 30 seconds). Monitor the Server's resource consumption (printed by Server Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
15904      205     1

• Stop the Client and Server.
• Set the following property at the Server side by modifying s.sh:

vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle=15

• Re-start the Server:
  • s.sh 1
• Re-start the Client:
  • c.sh 1 1 200
• After the Client has completed all the invocations, wait for some time (about 30 seconds). Monitor the Server's resource consumption (printed by Server Monitor). E.g:

MEMORY(KB) THREADS SOCKETS
12856      4      1

Observations

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.

Key observations after tuning:

• The idle worker threads in the Server are destroyed earlier.
• The memory usage by the Server is reduced earlier.

Explanation

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.

Back  | Next