Thread Pool Dispatcher threadMaxIdle

Thread Pool Dispatcher threadMaxIdle

[[Thread Pool Dispatcher threadMax|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" [[Explanation of Example|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.

Server Memory (KB)  Server Threads Server Sockets
Before Tuning 15904 205 1
After Tuning 12856 4 1

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.

[[Thread Pool Dispatcher threadMax|Back]]  | [[Thread Pool Performance|Next]]

Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
2 of 2
Last update:
‎2020-03-13 21:06
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.