Back

While running the example with the default configuration in the previous article, some of you may have noticed that the Client socket usage drops from 10 to 5 immediately after all the invocations to the 10 Servers have completed. This behavior is due to the "vbroker.ce.iiop.ccm.connectionCacheMax" property setting, which we will be discussing in this article.

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

The "echo_service_cpp" example is used in this demonstration.

Scenario

• Start 1 Client to call 10 Servers.
• 2 client threads are created by the Client to call each Server concurrently.
• Each client thread calls the Server once.
• Each invocation blocks for 10 seconds at the Server side.
• Monitor the Client's resource consumption and invocation performance with the default configuration.
• Observe the effect of setting Client Engine "connectionCacheMax=10".

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 Client Monitor script:
  • mon_c.sh
• Start the 10 Servers:
  • s.sh 10
• Start the Client:
  • c.sh 1 10 2
• After the Client has completed all it's invocations, wait for some time (about 5 seconds). Monitor the Client's resource consumption (printed by Client Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
12320      1       5

• Stop the Client and 10 Servers.
• Set the following property at the Client side by modifying c.sh:

vbroker.ce.iiop.ccm.connectionCacheMax=10

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

MEMORY(KB) THREADS SOCKETS
12320      1       10

Observations

Compare the resource consumption measurement of the idle Client before and after  tuning “vbroker.ce.iiop.ccm.connectionCacheMax=10” property at the Client side.

Key observations after tuning:

• The number of Client sockets that remains established (after all the invocations have completed) is greater.

Explanation

The "vbroker.ce.iiop.ccm.connectionCacheMax" property (default value is 5) specifies the maximum number of unused connections that can be cached by the VBC Client. A connection is considered in use as long as it is still being referenced by any CORBA Object. When the Object is destroyed, it's associated connection is also released. If this connection is not referenced by any other Object, then it is added to the cache. In the default configuration, only 5 connections are allowed in the cache, even though 10 connections are used when running the example. The older connections in the cache are closed and removed as newer ones are added so as to maintain the default "connectionCacheMax" limit of 5. That's why you can only see 5 client sockets after all the invocations have completed. When the "connectionCacheMax" limit is increased to 10, all the 10 unused connections can be cached, hence you can see 10 client sockets.

There are some benefits in caching unused connections. For example, if the Client needs to make subsequent invocations to the same Servers, it can quickly reuse the existing cached connections instead of re-establishing new connections to these Servers. This can reduce the latency of the subsequent invocations because the TCP connection establishment process is relatively slow.

So does this mean that higher "connectionCacheMax" limit always leads to better overall application performance? No. This is because too many cached connections will lead to the file descriptor resource issue as discussed in the Server Engine connectionMax article. The effectiveness of the cache depends mainly on the cache hit rate, which depends on the invocation pattern of the Client application. For example, if the Client frequently sends requests to the same set of Servers, then the cache hit rate will be high. In this case, increasing the "connectionCacheMax" limit may improve invocation performance. However, if the requests are frequently sent to many different Servers, then the cache hit rate will be low. In this case, increasing the "connectionCacheMax" limit will not lead to better invocation performance. Furthermore, the overall application performance may be affected because more file descriptor resources are consumed. To find out the optimal value for "connectionCacheMax", you must understand your application behavior and perform benchmark and stress tests.

The actual number of connections in the cache can also be influenced by the "vbroker.ce.iiop.ccm.connectionMax" property setting, which is equal to the number of active connections plus cached connections. For example, a cached connection may be closed and removed when a new connection is established in order to maintain the "connectionMax" limit.

Please note that the meaning of "connectionCacheMax=0" is unlimited cache, instead of zero cache size. If you want to disable the cache (i.e. unused connections are immediately closed instead of cached), you need to set the property "vbroker.ce.iiop.ccm.disableConnectionCache=true". The "disableConnectionCache" property is only applicable to VBC Client, not VBJ Client.

Back  |  Next