Back

In this article, you will learn how to influence the performance of a VBC Server by tuning the Thread Pool Dispatcher “vbroker.se.<se_name>.scm.<scm_name>.dispatcher.unlimitedConcurrency” property.

Note that this property is only applicable to VBC Server, not VBJ Server.

The "echo_service_cpp" example is used in this demonstration.

Scenario

• The Client creates 100 threads to call 1 Server concurrently.
• Each client thread calls the Server once.
• Each invocation blocks for 10 seconds at the Server side.
• Monitor the Server's resource consumption and invocation performance with the default configuration.
• Observe the effect of setting “unlimitedConcurrency=true”.

Can you guess how many threads will be created by the Server to service all the invocations ?

How long do you think the Client will take to complete all the invocations?

How many sockets do you think are required to service the concurrent invocations from 100 Client threads?

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.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
• Take note of the Server's resource consumption before servicing any request (printed by Server Monitor). E.g:

MEMORY(KB) THREADS SOCKETS
12096      4       0

• Start the Client:
  • c.sh 1 1 100
• Monitor the Server's resource consumption (printed by Server Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
12248      13      1

• Note the total time to complete all invocations (printed by Client). E.g.:

Total Time taken for 100 threads in PID 8965 to complete all invocations is 120.18 seconds

• 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.unlimitedConcurrency=true

• Re-start the Server:
  • s.sh 1
• Re-start the Client:
  • c.sh 1 1 100
• Monitor the Server's resource consumption (printed by Server Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
13136      105     1

• Note the total time to complete all invocations (printed by Client). E.g.:

Total Time taken for 100 threads in PID 20477 to complete all invocations is 10.0805 seconds

Observations

Compare the resource consumption and invocation performance measurement before and after  tuning “vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.unlimitedConcurrency=true” property at the Server side.

Key observations after tuning:

• Total time taken for all the threads to complete invocations is lesser.
• The memory usage by the Server is higher.
• The number of threads created by the Server is greater.

Explanation

By default the Thread Pool Dispatcher “unlimitedConcurrency” property is "false", which implies that the VBC ORB will control the thread creation using an internal algorithm based on heuristics when the "threadMax=0" (default value).

Note that VBJ does not have the feature that creates worker threads based on heuristics, and the “unlimitedConcurrency” property is also not applicable. In fact, setting "threadMax=0" for VBJ means that unlimited number of worker threads can be created, which has the same effect as setting “unlimitedConcurrency=true” and "threadMax=0" for VBC .

Although the default setting uses less memory and creates less number of threads to service the requests, it limits the performance if many blocking operations are called concurrently. In practice, this is a very common use case in a multi-tier distributed applications architecture. For example, a server making a slow synchronous call to another server before returning the reply back to the client is similar to this use case.

Do you notice that only one socket is used to service the concurrent invocations from the 100 Client threads? This is because by default, all invocations from a Client to the same server end-point are multiplexed over the same socket, even if the requests originate from different Client threads. VisiBroker connection management is designed to re-use existing established sockets whenever possible to optimize socket resource usage during invocations.

This example shows that sometimes you need to make a trade-off between resource consumption (memory/threads) and invocation throughput when tuning your application.

In the next article, you will learn how to tune the Thread Pool Dispatcher "threadMax" property to ensure your application is stable during high load.

Back  |  Next