BEA WebLogic Server Tuning Guide

10
When using the Java socket multiplexer (identified by –Dweblogic.nativeIOEnabled = false), the default queue also
determines the number of threads that can do socket reading work for a WebLogic Server instance, which is
specified as a percentage of the total number of threads configured in the default execute queue. The number of
socket readers configured, the multiplexer mechanism, and the expected number of socket connections to a
WebLogic Server has important bearing on the default execute queue thread count. WebLogic Server socket
handling is discussed below.
When the native socket multiplexer is used (identified by –Dweblogic.nativeIOEnabled=true, which is the default for
WebLogic Server 8.1 on an HP NonStop server), the socket readers are configured from a separate execute queue.
Moreover, the number of socket readers is very small (by default, 3). These socket readers use operating system
facilities (select() in most Unix systems and an equivalent thread-aware select() function on the NonStop server),
which allows the threads to wait for an IO event instead of polling them. This provides significant savings by
reducing the CPU usage, reducing the number of threads in the default execute queue, and simplifying the
configuration of the default execute queues.
WebLogic Server also has an experimental NIO multiplexer (that is not supported). NIO is the J2SE package for
new IO handling capabilities in the Java Platform. One of the new capabilities is the ability to wait for IO events on
multiple sockets channels.
2.7 WebLogic Server Socket Handling
WebLogic Server uses a socket multiplexer architecture whereby socket requests are read by a set of threads and
forwarded to other execute threads for further processing (thus tying into the staged processing architecture of
WebLogic Server). The socket multiplexer architecture lets any of the socket reader threads multiplex between many
sockets to check for the readiness of the sockets and read request data off them.
WebLogic Server provides native code socket multiplexers for many of the operating system platforms that
WebLogic Server runs on. This socket multiplexer uses system provided wait primitives (like the poll, select or other
system calls) to wait for ready events on sockets and process them. This also means that only one thread needs to
wait for sockets.
For those platforms where the native socket multiplexer is not available, WebLogic Server uses a multiplexer written
in pure Java. While the Java 1.4 platform (used by WebLogic Server 8.1) provides support for non-blocking
operations in the NIO package, a socket multiplexer using this facility is not supported by WebLogic Server, due to
lack of functionality and performance issues.
To work with the platforms without a native socket multiplexer, WebLogic Server uses the socket timeout facility. A
pool of socket readers periodically polls all available sockets for data. Instead of waiting indefinitely, a timeout is
set on the socket so that if the socket is not ready with data within the specified timeout, the socket reader thread
moves on to poll the next available socket. This mechanism is less efficient than the native polling mechanism.
3.0 Configuration Guidelines
3.1 Configuring WebLogic Server on HP NonStop Server for Accessing SQL/MX
As shown earlier, to access a database an application looks up a Datasource object configured in a WebLogic
Server instance (using JNDI) and acquires JDBC connections from the Datasource object. WebLogic Server JDBC
Datasource objects, which can be transactional or non-transactional, act as the interface between applications and
the JDBC connection pool.
The Datasources use connection pools configured within WebLogic Server for acquiring connections. When a
Connection pool is configured in WebLogic Server, the JDBC driver providing the connections for the connection