The Java NIO technology has been around since JDK 1.4. But by default, the VBJ Server utilizes standard Java IO for socket communications with the Clients. You can configure the VBJ Server to use Java NIO technology by setting the property "vbroker.se.<se_name>.scm.<scm_name>.manager.type=Socket_nio".
Note that this property is only applicable to VBJ Server, not VBC Server.
The "echo_service_java" example is used in this demonstration.
How many threads are created at the VBJ Server side to service all the invocations from the 10 Clients?
Configure the Client by modifying c.sh:
Configure the Server by modifying s.sh:
Make sure you have set up the necessary VisiBroker environment and build the example before running this demonstration.
MEMORY(KB) THREADS SOCKETS
74968 32 10
MEMORY(KB) THREADS SOCKETS
74912 23 10
Compare the resource consumption measurement of the VBJ Server before and after tuning “vbroker.se.iiop_tp.scm.iiop_tp.manager.type=Socket_nio” property at the VBJ Server side.
|Server Memory (KB)||Server Threads||Server Sockets|
Key observations after tuning:
A VBJ Server can be configured to use the Java NIO feature by setting the property "vbroker.se.<se_name>.scm.<scm_name>.manager.type=Socket_nio". The default value is "Socket", which configures the VBJ Server to use the standard Java IO.
Using Java NIO technology enables the VBJ Server to handle a larger number of concurrent client connections with fewer threads compare to using standard Java IO. This translates to higher scalability as lesser thread resources are required to handle more clients.
The standard Java IO implementation requires a Worker Thread per established connection to wait for (and read) any new request message that may arrive. This implies that the number of Worker Threads needed to just listen at the connections varies directly with the number of connections. Including those Worker Threads which are doing the actual work (i.e. executing the application method implementation), the total thread and memory resource consumption can become a concern for large number of connections.
The Java NIO implementation does not have this thread per connection overhead. Only one listener thread is needed to listen to all the established connections. The Worker Threads are dispatched to service the requests only when new requests arrive at the connections. That is why Java NIO feature may scale better when the number of concurrent client connections is very large.
Whether Java NIO feature can bring about better performance to your VBJ Server depends on the nature of your application. For example, a Server receiving requests from a few clients will benefit less from Java NIO feature compare to a Server receiving requests from a huge number of clients. So you must perform benchmark tests to find out the appropriate setting that is suitable to your application.