[[QoS Relative Round Trip Timeout|Back]] In the previous article, you have learnt that the QoS Relative Round Trip Timeout Policy can be set with the property " vbroker.orb.qos.relativeRTT " for VBJ Client. This property works fine in most circumstances, however, in one unique scenario, it may result in relatively higher thread and memory resources consumption by the VBJ Client. If the Client resource is limited and cannot be increased, this may destabilize the whole application. The scenario we mentioned above is when a VBJ Client needs to establish and maintain connections to a large number of Servers (e.g. a few thousands) in parallel. In this scenario, setting the " vbroker.orb.tcpTimeout " and " vbroker.orb.socketTimeoutMonitorPeriod " properties may be a better choice, as lesser thread and memory resources are consumed . We will discuss and compare these 2 approaches and their side effects in this article, so that you can make an informed decision when tuning round trip timeout for your VBJ Client application. Note that all these properties are only applicable to VBJ Client, not VBC++ Client. The "echo_service_java" [[Explanation of Example|example]] is used in this demonstration. Scenario The VBJ Client creates 10 threads to call 10 Servers concurrently. Each client thread calls each Server once. Each call blocks for 10 seconds at the Server side. Set " vbroker.orb.qos.relativeRTT=9000 " at VBJ Client (to trigger TIMEOUT exception after 9 secs). Monitor the VBJ Client's resource consumption with this setting. Observe the effect of setting " vbroker.orb.tcpTimeout=9000 " and " vbroker.orb.socketTimeoutMonitorPeriod=5000 " at VBJ Client. Preparation Configure the Client by modifying c.sh: Set the following properties: vbroker.orb.qos.relativeRTT=9000 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 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 1 Monitor the Client's resource consumption after all the invocations have timeouted (printed by Client Monitor). E.g.: MEMORY(KB) THREADS SOCKETS 74880 20 10 Take note of the time taken for each invocation to timeout (printed by Client). E.g.: . . . . . . Client Thread Id P8412_T0_S7 caugut org.omg.CORBA.TIMEOUT: Read timed out vmcid: OMG minor code: 0 completed: Maybe, time taken is 9.008000 seconds Client Thread Id P8412_T0_S8 caugut org.omg.CORBA.TIMEOUT: Read timed out vmcid: OMG minor code: 0 completed: Maybe, time taken is 9.004000 seconds Stop the Client and Server. Disable “ vbroker.orb.qos.relativeRTT=9000 ” and set the following properties at the Client side by modifying c.sh: vbroker.orb.tcpTimeout=9000 vbroker.orb.socketTimeoutMonitorPeriod=5000 Re-start the 10 Servers: s.sh 10 Re-start the Client: c.sh 1 10 1 Monitor the Client's resource consumption after all the invocations have timeouted (printed by Client Monitor). E.g.: MEMORY(KB) THREADS SOCKETS 74560 11 10 Take note of the time taken for each invocation to timeout (printed by Client). E.g.: . . . . . . Client Thread Id P8577_T0_S6 caugut org.omg.CORBA.TIMEOUT: Read timed out vmcid: OMG minor code: 0 completed: Maybe, time taken is 9.004000 seconds Client Thread Id P8577_T0_S7 caugut org.omg.CORBA.TIMEOUT: Read timed out vmcid: OMG minor code: 0 completed: Maybe, time taken is 9.008000 seconds Observations Compare the resource consumption of the Client before and after tuning the properties " vbroker.orb.tcpTimeout=9000 ” and " vbroker.orb.socketTimeoutMonitorPeriod=5000 " at the VBJ Client side. Client Memory (KB) Client Threads Client Sockets Before Tuning 74880 20 10 After Tuning 74560 11 10 Key observations after tuning: The number of threads created by the VBJ Client is lesser. The memory usage by the VBJ Client is lesser. Explanation From our simple demonstration, it seems that the combined properties of " vbroker.orb.tcpTimeout " and " vbroker.orb.socketTimeoutMonitorPeriod " is able to achieve the same timeout behavior as the " vbroker.orb.qos.relativeRTT " property, but by using much lesser thread and memory resources. In fact, you increase the number of established connections, the difference in resource usage between the two approaches will become even greater. If you rerun the example with 20 Servers, the Client resource consumption should be similar to the following: 1st Approach : Client's resource consumption using " vbroker.orb.qos.relativeRTT ". E.g.: MEMORY(KB) THREADS SOCKETS 76384 30 20 2nd Approach : Client's resource consumption using " vbroker.orb.tcpTimeout " and " vbroker.orb.socketTimeoutMonitorPeriod ". E.g.: MEMORY(KB) THREADS SOCKETS 75768 11 20 Do you notice that even though the Client's socket count is increased by 10 (from 10 to 20), the thread count of the 2nd Approach remains constant at 11. In contrast, the thread count of the 1st approach increases by 10 (from 20 to 30). This shows that the 2nd Approach is more scalable than the 1st Approach if your Client needs to establish and maintain connections to a large number of Servers in parallel. As you may have deduced from the test result of the 1st Approach, 1 thread per connection is required to enforce the round trip timeout. If the connection count is relatively low, you can easily tune the JVM to cater for the additional threads and memory required. However, for relatively higher connection count (e.g. a few thousands), this approach may not be feasible if the resources in the JVM is limited. In this case, the 2nd Approach may be a better choice since the thread count is constant regardless of the number of connections. The 2nd Approach seems like a more efficient and cost-effective method to achieve similar timeout requirement, but is there any side effect? Yes, it may be less accurate than the 1st Approach if the timeout occurs when the Client is writing the Request Message to the socket while making a method invocation. This rare situation may occur during very high load or network congestion which may cause the socket buffer to be full. This can result in the time needed to write the Request Message to be longer than round trip timeout set. The 1st Approach is more accurate because every connection has a dedicated thread monitoring and triggering the timeout, while the 2nd Approach uses only a single monitoring thread to verify the timeout at all the connections periodically. The time period is specified (in milliseconds) using the property " vbroker.orb.socketTimeoutMonitorPeriod ". Hence, it is possible that the actual timeout can occurs after "tcpTimeout" plus "socketTimeoutMonitorPeriod" in this situation. However, you must refrain from setting "socketTimeoutMonitorPeriod" to a small value, otherwise the excessive timeout checking by the monitoring thread will consume too much CPU resource. The default value of 0 for "socketTimeoutMonitorPeriod" means that the monitoring thread is not started. This also means that the "tcpTimeout" specified for the invocation only comprise of the time allowed to wait for the Reply Message, but the time allowed to write the Request Message is unlimited. This may lead to delayed and inaccurate timeouts during very high load or network congestion scenario. Note that "tcpTimeout" behavior will override/disable the Relative Round Trip Timeout Policy (or "relativeRTT") if both type of timeouts are set together. So to avoid confusion, you should not set these two types of timeout policies together. Furthermore, the "tcpTimeout" timeout behavior is currently only supported at the ORB Level. If your VBJ Client need to communicate with a large number of Servers, but not concurrently, you can consider using the 1st Approach but in combination with "[[Client Engine connectionMax| vbroker.ce.iiop.ccm.connectionMax ]]" and/or "[[Other Connection Tuning| vbroker.ce.iiop.ccm.connectionMaxIdle "]]" to restrict the number of concurrent connections and limiting the socket and thread resources consumption. However, you need to consider the side effects of setting these two properties as discussed in the two articles. In order to choose the most appropriate round trip timeout approach and timeout value, you need to know the expected load (especially the number of connections at the VBJ Client side) and your Client JVM resource limitation. After that, you need to tune the Client and perform some stress tests to ensure the application is stable under high load. [[QoS Relative Round Trip Timeout|Back]] | [[Other QoS Timeout Tuning|Next]]
↧