Server Engine connectionMaxIdle

Server Engine connectionMaxIdle

[[Server Engine connectionMax|Back]]

While running the previous example in [[Server Engine connectionMax|Server Engine connectionMax]], did you notice that the connections created by the Server to service the 10 Clients are never closed, even after all the requests have been serviced? Is there any way to close these idle connections to conserve resources?

Yes. You can accomplish it by setting the Server Engine “vbroker.se.<se_name>.scm.<scm_name>.manager.connectionMaxIdle” property.

The "echo_service_cpp" [[Explanation of Example|example]] is used in this demonstration.

Scenario

  • Start 10 Clients which create 2 threads each 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 of the idle Server after all the invocations have completed.
  • Observe the effect of setting Server Engine "connectionMaxIdle=15".

Can you guess how long it will take before the idle connections are closed?

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=100
    • 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 10 Clients:
    • c.sh 10 1 2
  • After all the Clients have completed their invocations, wait for some time (about 30 seconds). Monitor the Server's resource consumption (printed by Server Monitor). E.g.:

MEMORY(KB) THREADS SOCKETS
12544      34      10

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

vbroker.se.iiop_tp.scm.iiop_tp.manager.connectionMaxIdle=15

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

MEMORY(KB) THREADS SOCKETS
12544      34      0

Observations

Compare the resource consumption measurement of the idle Server before and after  tuning “vbroker.se.iiop_tp.scm.iiop_tp.manager.connectionMaxIdle=15” property at the Server side.

Server Memory (KB)  Server Threads Server Sockets
Before Tuning 12544 34 10
After Tuning 12544 34 0

Key observations after tuning:

  • The idle connections are closed by the Server after the "connectionMaxIdle" timeout, instead of waiting for the Clients to close them.

Explanation

As you can see, the Server does not close any idle connections from the inactive (but still alive) Clients by default (i.e. vbroker.se.<se_name>.scm.<scm_name>.manager.connectionMaxIdle=0). The connections are only destroyed when they are closed at the Client side. However, if you set the Server Engine “connectionMaxIdle” property, the Server side will initiate the closure of  idle connections.

You may have observed that the idle connections are closed slightly later than the “connectionMaxIdle” time. This is expected because the VBC++ Server side garbage collection for idle connections routine is only triggered periodically. The frequency to perform this routine is controlled by the "vbroker.se.<se_name>.scm.<scm_name>.manager.garbageCollectTimer" property. The default  value for this timer is 30 seconds.

Note that the Server Engine "connectionMaxIdle" property is applicable to VBJ, but the "garbageCollectTimer" property is not. The equivalent property in VBJ is "vbroker.orb.gcTimeout", which also has a default value of 30 seconds.

As explained in the previous [[Server Engine connectionMax|article]], the number of sockets that can be created is bounded by the file descriptor limit of the process, so releasing idled connections managed by VisiBroker will allow other modules in the same process to use them. However, the “connectionMaxIdle” feature has similar side effect as explained in the previous [[Server Engine connectionMax|article]], that is, the existing Clients that have their connections closed by the Server will need to re-establish their connections for subsequent invocations.

This feature is useful when a large number of clients are making infrequent calls to the Server. A good example is the Naming Service usage scenario. A typical client connects to the Naming Service and make "resolve" call during initialization to obtain the Server's IOR. Thereafter, this connection usually remains idle because the subsequent invocations are only made to the Server. In this case, the closure of idle connections by Naming Service is unlikely to cause any performance issue.

This feature is also useful in the situation where the clients' connections are silently dropped for a number of possible reasons such as machine crash, network outage, power failure or the firewall dropping idle connections. Since neither TCP FIN nor RST packet is received from these dropped connections, the Server continues to retain them unless "connectionMaxIdle" is set. These stale connections are a waste of the process's file descriptor resource, and they should be destroyed.

Similar to tuning the other properties, you need to understand the overall behavior and deployment scenarios of your application when tuning the Server Engine "connectionMaxIdle" property.

In the next article, you will learn more about tuning the Client side Connection Management properties to control the socket resource usage.

[[Server Engine connectionMax|Back]]  |  [[Client Engine connectionMax|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.