This section contains additional SNA performance tuning hints and tips for use with DB2 Connect.
The performance characteristics of DB2 Connect are that it predominantly uses the processor and performs very little I/O. In general, the faster the processor speed, the faster DB2 Connect will run. DB2 Connect fully exploits SMP processor configurations.
A fast DB2 Connect Enterprise Edition server can handle an SQL request/reply pair in less than five milliseconds, not counting client time, network time, and processing time at the host or AS/400 server. A simple SQL statement or query with a few rows of data could be completed end-to-end in less than 0.1 seconds (from client to the host or AS/400 server and back).
When there are more than four or five SQL statements in a query, then the use of stored procedures will help to ensure high OLTP performance and to avoid increases in lock contention due to network delays between SQL statements.
Performance problems are usually caused by to the type of host attachment in use, network routing and tuning characteristics, and application design. Some general DB2 Connect performance information can be found in Other DB2 Connect Performance Information Sources.
In order of likely best performance when using DB2 Connect, various types of network attachment include:
The last option is not recommended - see below.
The recommended best way to connect to the host is to use ESCON channel attachment cards for AIX, Windows NT or Windows 2000. The IBM 3172 Model 3 and 2216 also perform well, but they tend to deliver throughput inferior to ESCON.
When using AIX with ESCON cards, please apply the PTFs related to MPC (Multi Path Channel). Without these PTFs the AIX SNA ESCON driver may deliver worse performance. See Multi Path Channel Support for SNA over ESCON for more details. Further information can also be found at: http://www.networking.ibm.com.cms/cmsnew01.html
See How to Tune DB2 Connect Connections via NCP for a checklist of which Communications Server, NCP, and VTAM parameters to tune to optimize DB2 Connect performance. All the non-NCP specific recommendations are applicable to all types of DB2 Connect and client/server attachments.
The OSA-2 card on System/390 might not deliver throughput as high as a 3272 Model 3 when there is a high volume of small transactions, owing to its lower frames-per-second capability. See Information about OSA-2 Enhancements for details of some recent enhancements.
3145 with NCP is usually tuned specifically for existing network traffic. Consequently it might not perform as well for database client/server applications. Most DB2 Connect performance problems are due to the time delay between the NCP and VTAM and/or between NCPs. See How to Tune DB2 Connect Connections via NCP, which provides a tuning checklist.
In general, we recommend avoiding the use of 3174 Terminal Controllers because their packet size (RU size) of 256 bytes is too small. 3174 microcode level C is required in order to provide Independent LU support for APPC database connections. Some OEM 3174 equivalents may have similar dependencies.
Multi Path Channel (MPC) support for SNA over ESCON allows a system running IBM eNetwork Communications Server to use an ESCON adapter to create an MPC linkstation to the host. MPC is typically faster than CDLC because:
Tests have shown as much as a threefold improvement on an MPC link compared to an ESCON Channel Data Link Control (CDLC) link with an IOBUF size less than 1K. AIX SNA MPC requires ESCON and MVS VTAM V4R4 or later and feature code 4024 of Communications Server for AIX (5765-652). Windows NT systems must use IBM eNetwork Communications Server for Windows NT Version 6.
The following are the Communications Server for AIX PTFs required for MPC:
APAR # PTF # LPP name
IX67032 U449693 sna.books.chdoc
IX67032 U449693 sna.books.escdoc
IX67032 U449300 sna.rte
IX67032 U450027 sna.msg.en_US.rte
IX65820 U447759 sna.dlcchannel
IX67618 U449691 mpc.rte
IX65813 U447758 devices.mca.8fc3.rte
A typical network configuration might be:
Figure 8. DB2 Connect Enterprise Edition gateway SNA network scenario
|
This scenario focuses on the throughput and response time between the host or AS/400 database server to the DB2 Connect Enterprise Edition gateway and various parameters that could affect this.
The suggested order in which to make these changes is:
1 - DELAY on PCCU macro* 2 - DLC/LLC Tuning* 3 - PIU size* 4 - Pacing window changes* 5 - DELAY on LINE macro* 6 - MAXBFRU changes 7 - LAN Frame sizes * Major improvement in throughput is possible
The RU size at the host and the DB2 Connect server should be maximized. This implies that the RU size should be large enough to contain the API crossing (both SEND and RECEIVE data for the transaction where possible) in order to minimize the number of times VTAM program stack must be traversed. Also, the network frame size may limit the maximum RU size if RU segmentation is not desired.
It is a good idea to set the DB2 Connect block size (RQRIOBLK), RU and pacing values such that RU * pacing >= RQRIOBLK. For example, the default RQRIOBLK size of 32K is a good value for most situations, and to exploit this you would set RU = 4K and receive window pacing to 8.
The session and VR pacing windows should be maximized: the largest value that does not cause network congestion or VR-held conditions, and so on, should be used. For a test environment set pacing to 0 (no pacing) or set it to the maximum value X'3F'.
Coat-tailing is controlled by the DELAY parameter. The DELAY Parameter in the PCCU macro controls outbound coat-tailing (outbound with reference to the host). The DELAY value in the LINE definition statement for the NCP controls inbound coat-tailing (inbound with reference to the host).
The DELAY value determines how long a PIU is held in the queue (NCP or VTAM) before it is transmitted. The purpose of this wait is to increase the possibility that other PIUs will arrive in the interim and all of these can be transmitted on a single channel program. For the lowest latency, the DELAY value should be set to 0. Changing the value of the outbound coat-tailing delay value to 0 should have no noticeable effect on the host except for improved performance for outbound traffic. Some improvement in inbound traffic performance will also be realized.
Changing the DELAY on the NCP to 0 should be done with a little more care. The value can be set to 0 if the NCP is not overloaded and the inbound traffic does not consist of a significant percentage of small frames. Setting the values of DELAY to 0 may improve response time significantly, especially under light loads or test/benchmark environments.
VTAMB7 PCCU CUADDR=CAF,
AUTODMP=NO,
AUTOIPL=NO,
AUTOSYN=YES,
BACKUP=YES,
DELAY=0,
VFYLM=YES,
CHANCON=UNCOND,
MAXDATA=32768,
DUMPDS=NCPDUMP,
OWNER=HOSTB7,
SUBAREA=17
LNCTLS GROUP LNCTL=CA,CA=TYPE6,DELAY=0.0,TIMEOUT=500.0
CA0 LINE ADDRESS=00
PUCHAN0 PU PUTYPE=5,TGN=1
CA1 LINE ADDRESS=01
PUCHAN1 PU PUTYPE=5,TGN=1
DELAY considerations are documented in the VTAM Network Implementation Guide.
The MAXBFRU value should be set to a value two or three times larger than the largest PIU size.
Ensure that the LLC2 window sizes (DLC send and receive window counts) between the NCP and the DB2 Connect Enterprise Edition gateway are the same. This has a significant effect specially when the server is DB2 Connect for AIX. It is recommended that the send window count be set higher than the receive window count.
In general, for any SNA connection across a Token-ring the LLC2 timers/windows should be optimized. In some cases, this change led to a six-fold improvement in throughput and response time.
The token ring maximum frame size should be as large as possible.
The following information is reproduced from the IBM WSC Flash document number 9718.
TITLE: WSC FLASH 9718: OSA-2 ENHANCEMENTS AVAILABLE
DOCUMENT ID G023691 UNCLASSIFIED
Open Systems Adapter 2 (OSA-2) Systems Network Architecture (SNA)
enhancements are being made available earlier than previously announced.
The enhancements are:
o SNA/APPN enhancements for OS/390, MVS/ESA, VM/ESA, and VSE/ESA
- Enhanced availability: load balancing, redundancy, and overflow
- Enhanced connectivity: increased Physical Unit (PU) support
(from 255 PUs per port to 2047 PUs per port).
o Support for ACF/VTAM for VSE/ESA networks
NOTE: These enhancements do not pertain to OSA-1.
LOAD BALANCING, REDUNDANCY, AND OVERFLOW ________________________________________ LOAD BALANCING: A single Medium Access Control (MAC) address can now be defined for attached OSA-2 SNA/APPN Physical Units (PUs), even though connections may be via multiple physical ports. This support is offered for source-route bridged environments only (Token-Ring and FDDI). The number of sessions established through a port is monitored, and user session loads are evenly distributed across the equally configured ports. REDUNDANCY: A secondary path between the LAN workstation and the host system can now be configured. If the primary path becomes unavailable, the secondary path will receive the LAN traffic. This increases system availability and simplifies network management. OVERFLOW: User sessions flow through the primary OSA-2 port until the session capacity has been reached. Additional user sessions will automatically flow to the next OSA-2 port. Since all user workstations are identically configured, network administration is simplified and the network becomes more scalable. New users can be added non-disruptively. Load balancing, redundancy, and overflow support is provided by PTFs for OSA/SF as follows: o OS/390 and MVS - OW20205/UW34618 03/31/97 o VM/ESA - OW23952/UW37028 03/31/97 o VSE/ESA - Provided with VSE/ESA V2.2.1 04/29/97
INCREASED PHYSICAL UNIT (PU) SUPPORT (VIA OSA/SF):
__________________________________________________
The architecture has been changed to allow up to a maximum of 2047 PUs per
physical port to be defined for OSA-2 Ethernet, Token-Ring and FDDI features
instead of the current 255 PUs per port. This enhancement is available for
currently installed features, as well as new installations. Actual
connectivity may vary based upon user workloads.
Increased Physical Unit (PU) Support is provided by PTFs for OSA/SF as
follows:
o OS/390 and MVS - OW23429/UW37210 03/31/97
o VM/ESA - OW24952/UW37028 03/31/97
o VSE/ESA - PQ03091/UQ04224 04/29/97
Increased Physical Unit (PU) Support is provided by PTFs for ACT/VTAM as
follows:
o ACF/VTAM for OS/390 and MVS
- VTAM 4.1 OW14043/UW24904
- VTAM 4.2 OW14043/UW24905
- VTAM 4.3 OW14043/UW24906
o ACF/VTAM VM/ESA
- VM60877/UV59834
o ACF/VTAM VSE/ESA
- DY44347/UD50254
VSE/ESA - SNA SUPPORT
_____________________
OSA-2 and OSA/SF support is delivered via VSE/ESA Version 2 Release 2.1. This
announcement of VSE/ESA support satisfies the Statement of General Direction
contained in Hardware Announcement 196-194, and Hardware Announcement
196-193, dated September 10, 1996.
The OSA-2 feature provides ACF/VTAM for VSE/ESA host applications with direct
access to Ethernet, Token-Ring, and FDDI LANs and Asynchronous Transfer Mode
(ATM) Forum-compliant LAN emulation networks.
OSA/SF is available:
o As a non-exclusive element of OS/390 Release 1 or above (5645-001)
o As a separate program product, S/390 Open Systems Adapter Support
Facility Version 1 Release 2 for MVS/ESA 4.3 or above (5655-104)
o As a facility of VM/ESA Version 2 Release 2.0 (5654-030)
o As a component of VSE Central Functions 6.1.1 in VSE/ESA Version 2
Release 2.1 (5690-VSE).
MORE INFORMATION
________________
Announcements 297-043, 297-040