What about parameter weblogic.PosixSocketReaders in WLS 8.1

Question

Hi,
I would want to know what is the effect of the parameter weblogic.PosixSocketReaders in wls 8.1?
The only doc i can read on this subject is http://e-docs.bea.com/wls/docs70/perform/appb_tunetips.html and concerne wls 7.
Which is the effect if I put this parameter at value 1 (with wls81 and native i/o)?
Thanks.

Answer 1

CASE_ID_NUM: 642649
PosixSocketReaders and how they work in WLS:
WLS utilizes native code to perform socket handling, called the performance pack. Native code polls sockets on the OS layer if a new socket and data has to be processed, if a socket contains data that WLS is supposed to process it is picked up by Java threads from the WLS SocketReader thread queue. The SocketReader Java threads have the task of passing the socket and the contained raw message to an execute thread performing the application specific processing.
The flow of a socket and data from the OS to WLS is as follows:
OS TCP/IP Socket --> WLS native code (performance pack) polls for sockets --> Java SocketReader thread -- dispatch --> WLS Java execute thread (e.g. execute thread from default WLS execute queue)
The number of SocketReader threads is per default set to 3 on Unix environments, this is generally a good default value. In some case and specific OS environments experience has shown that tuning the number of SocketReader threads is beneficial to get the maximum performance from WLS in dispatching a socket from the native layer to a WLS execute thread.
The reason why tuning the SocketReaders can have an positive effect is based on two main factors:
1. SocketReader threads have many Java synchronization blocks as they are working very concurrently on the native code layer. 2. A big number of sockets being opened to WLS
In case the JVM and/or OS is not very good in handling synchronization locks point 1. is the limiting performance factor of Socketreaders as the JVM and OS are more busy handling Java synchronization locks than doing the actual dispatch work. For such a scenario experience with other customers has shown that using PosixSocketReaders=1 is beneficial
On the other side if the JVM and OS handle synchronization locks very well it can be beneficial to increase the number of PosixSocketReaders threads and thus allow WLS to dispatch more socket data from the native layer to a WLS execute thread in parallel.
As the performance of PosixSocketReaders very much depends on the OS / JVM and if the system/application is heavily socket/network related a good value for PosixSocketReaders has to be identified based on test runs. Generally the default value of 3 PosixSocketReaders is good for most applications and environments.