TCP/IP can be the source of some significant remote method delays. Follow these tips to tune TCP/IP:
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) .
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.
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.
TCPCONFIG TCPSENDBFRSIZE 65535 TCPRCVBUFRSIZE 65535
Note: It would not be unreasonable, in some cases, to specify 256K buffers.
protocol_http_backlog=100 protocol_https_backlog=100 protocol_iiop_backlog=100 protocol_ssl_backlog=100
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.
Note: Unless you have trouble using up sockets, we recommend that you leave this set to the default value.
If you are using z/OS V1.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