WebSphere® Application Server uses the TCP/IP
sockets communication mechanism extensively. For a TCP/IP socket connection,
the send and receive buffer sizes define the receive window. The receive
window specifies the amount of data that can be sent and not received
before the send is interrupted. If too much data is sent, it overruns
the buffer and interrupts the transfer. The mechanism that controls
data transfer interruptions is referred to as flow control. If the
receive window size for TCP/IP buffers is too small, the receive window
buffer is frequently overrun, and the flow control mechanism stops
the data transfer until the receive buffer is empty.
About this task
TCP/IP can be the
source of some significant remote method delays.
To change the system wide
value, perform the following steps:
Procedure
Tune the TCP/IP buffer sizes.
- First, ensure that you have defined enough sockets to
your system and that the default socket timeout of 180 seconds is
not too high. To allow enough sockets, update the BPXPRMxx parmlib
member:
- Set MAXSOCKETS for the AF_INET filesystem high enough.
- Set MAXFILEPROC high enough.
We recommend setting MAXSOCKETS and MAXFILEPROC to at least
5000 for low-throughput, 10000 for medium-throughput, and 35000 for
high-throughput WebSphere transaction environments. Setting
high values for these parameters should not cause excessive use of
resources unless the sockets or files are actually allocated.
Example:
/* Open/MVS Parmlib Member */
/* CHANGE HISTORY: */
/* 01/31/02 AEK Increased MAXSOCKETS on AF_UNIX from 10000 to 50000*/
/* per request from My Developer */
/* 10/02/01 JAB Set up shared HFS */
/* KERNEL RESOURCES DEFAULT MIN MAX */
/* ======================== =================== === =========== */
.
.
MAXFILEPROC(65535) /* 64 3 65535 */
.
.
NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(30000)
.
- Next check the specification of the port in TCPIP profile
dataset to ensure that NODELAYACKS is
specified as follows:
PORT 8082 TCP NODELAYACKS
In your runs, changing this could improve throughput by as
much as 50% (this is particularly useful when dealing with trivial
workloads). This setting is important for good performance when running
SSL.
- You should ensure that your DNS configuration is optimized
so that lookups for frequently-used servers and clients are being
cached.
Caching is sometimes related to the name server's
Time To Live (TTL) value. On the one hand, setting the TTL high will
ensure good cache hits. However, setting it high also means that,
if the Daemon goes down, it will take a while for everyone in the
network to be aware of it.
A good way to verify that your DNS
configuration is optimized is to issue the oping and onslookup USS
commands. Make sure they respond in a reasonable amount of time. Often
a misconfigured DNS or DNS server name will cause delays of 10 seconds
or more.
- Increase the size of the TCPIP send and receive buffers
from the default of 16K to at least 64K. This is the size of the buffers
including control information beyond what is present in the data that
you are sending in your application. To do this specify the following:
TCPCONFIG TCPSENDBFRSIZE 65535
TCPRCVBUFRSIZE 65535
Avoid trouble: It is unreasonable,
in some cases, to specify 256 KB buffers.
gotcha
- Increase the default listen backlog.
![[oct2010]](../../delta.gif)
The default listen backlog is used to buffer spikes
in new connections which come with a protocol like HTTP. The default
listen backlog is 10 requests. We recommend that you use the TCP transport
channel listenBacklog custom property to increase this value to something
larger. For example:
listenBacklog=100
![[oct2010]](../../deltaend.gif)
oct2010
- Reduce the finwait2 time. In the most demanding
benchmarks you may find that even defining 65K sockets and file descriptors
does not give you enough 'free' sockets to run 100%. When a socket
is closed abnormally (for example, no longer needed) it is not made
available immediately. Instead it is placed into a state called finwait2
(this is what shows up in the netstat -s command). It waits there
for a period of time before it is made available in the free pool.
The default for this is 600 seconds.
Avoid trouble: Unless you have trouble using up sockets, we recommend
that you leave this set to the default value.
gotcha
If you are using z/OS® Version
1.2 or above, you can control the amount of time the socket stays
in finwait2 state by specifying the following in the configuration
file:
FINWAIT2TIME 60
Results
Repeat this
process until you determine the ideal buffer size.
What to do next
The TCP/IP
buffer sizes are changed. Repeat this process until you determine
the ideal buffer size.