Dette afsnit indeholder flere tip til tuning af SNA-performance i forbindelse med DB2 Connect.
Med hensyn til performance gælder for DB2 Connect, at programmet primært bruger processoren og udfører begrænset I/O. Generelt vil DB2 Connect køre hurtigere, jo hurtigere processorhastigheden er. DB2 Connect udnytter konfigurationer med SMP-processorer fuldt ud.
En hurtig DB2 Connect Enterprise Edition-server kan håndtere en SQL-forespørgsel og svaret på den på mindre end fem millisekunder, når der ses bort fra klienttid, netværkstid og behandlingstid på værts- eller AS/400-databaseserveren. En simpel SQL-forespørgsel med et par datarækker kan være afsluttet fra start til slut på mindre end 0,1 sekund (fra klient til værts- eller AS/400-databaseserveren og tilbage).
Når en forespørgsel indeholder mere end fire eller fem SQL-sætninger, kan det være en fordel af bruge lagrede procedurer. Det vil sikre performance i et onlinetransaktionsmiljø og undgå, at antallet af låsekonflikter øges på grund af netværksforsinkelser mellem SQL-sætningerne.
Performanceproblemer er normalt relateret til den type værtstilslutning, der benyttes, netværksrutningen, tuning og applikationsdesign. Der er generelle oplysninger om DB2 Connect-performance i Andre oplysninger om DB2 Connect-performance.
Nedenfor vises eksempler på netværkstilslutninger, der er opstillet efter den sandsynligvis bedste performance sammen med DB2 Connect:
Den sidste mulighed anbefales ikke - se nedenfor.
Som den bedste tilslutningsmåde til værtssystemet anbefales ESCON-kanaltilslutningskort til AIX, Windows NT eller Windows 2000. IBM 3172 Model 3 og 2216 har også en god performance, men normalt lavere end med ESCON.
Hvis der bruges ESCON-kort til AIX, bør PTF'erne til MPC (Multi Path Channel) installeres. Uden PTF'erne kan styreprogrammet til AIX SNA ESCON give en dårligere performance. Der er flere oplysninger i MPC-støtte til SNA over ESCON. Der er også flere oplysninger på adressen http://www.networking.ibm.com.cms/cmsnew01.html
Under Tuning af DB2 Connect-forbindelser via NCP findes en checkliste med de Communications Server-, NCP- og VTAM-parmetre, der skal justeres for at optimere performance i DB2 Connect. Med undtagelse af NCP-værdierne gælder alle anbefalinger for alle typer DB2 Connect- og client/server-tilslutninger.
Hastigheden for OSA-2-kortet i System/390 kan være lavere end for 3272 Model 3, når der er mange små transaktioner, da kortet håndterer færre rammer i sekundet. Oplysninger om forbedringer af OSA-2 indeholder oplysninger om nye forbedringer.
3145 med NCP er normalt optimeret specifikt til den eksisterende netværksbelastning. Performance kan derfor være lavere for client/server-databaseapplikationer. De fleste DB2 Connect-performanceproblemer skyldes tidsforskydningen mellem NCP og VTAM og/eller mellem NCP'er. Se checklisten i Tuning af DB2 Connect-forbindelser via NCP.
Det anbefales generelt at undlade at anvende 3174 Terminal Controllers, fordi deres pakkestørrelse (RU-størrelse) på 256 byte er for lille. Der kræves mikrokodeniveau C til 3174 for at kunne benytte uafhængige LU'er til APPC-databaseforbindelser. 3174-lignende udstyr fra andre leverandører kan have tilsvarende afhængigheder.
MPC-støtte (Multi Path Channel) til SNA over ESCON giver systemer med IBM eNetwork Communications Server mulighed for at benytte en ESCON-adapter til at oprette en MPC-linkstation til værtssystemet. MPC er typisk hurtigere end CDLC, fordi:
Tests har vist en forbedring på op til 300 % ved et MPC-link i forhold til et ESCON CDLC-link (Channel Data Link Control) med en IOBUF-størrelse på mindre end 1 KB. AIX SNA MPC kræver ESCON og MVS VTAM Version 4 Release 4 eller nyere og feature-kode 4024 for Communications Server til AIX (5765-652). Windows NT-systemer skal anvende IBM eNetwork Communications Server til Windows NT Version 6.
Der kræves følgende PTF'er til Communications Server til AIX for at kunne anvende MPC:
APAR-nr. PTF-nr. LPP-navn 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
Herunder ses en typisk netværkskonfiguration:
Fig. 8. Eksempel på SNA-netværk med DB2 Connect Enterprise Edition-gateway
![]() |
I eksemplet fokuseres på kapaciteten og svartiden mellem værts- eller AS/400-databaseserveren og DB2 Connect Enterprise Edition-gatewayen og forskellige parametre, der kan have indflydelse på dem.
Det anbefales at udføre ændringerne i følgende rækkefølge:
1 - DELAY i PCCU-makro* 2 - Tuning af DLC/LLC* 3 - PIU-størrelse* 4 - Ændring af Pacing Window* 5 - DELAY i LINE-makro* 6 - Ændring af MAXBFRU 7 - LAN-rammestørrelse * Kan give en stor effektivitetsforbedring
RU-størrelsen bør være så stor som muligt på værtssystemet og DB2 Connect-serveren. Hvis det er muligt, bør RU'en være stor nok til at indeholde SEND- og RECEIVE-data for transaktionen, så VTAM-programstakken ikke skal gennemløbes flere gange end nødvendigt. Hvis man vil undgå RU-segmentering, kan netværkets rammestørrelse begrænse den maksimale RU-størrelse.
Det er en god idé at angive blokstørrelsen i DB2 Connect (RQRIOBLK), RU- og pacing-værdier, så RU * pacing >= RQRIOBLK. Standardstørrelsen på 32 KB for RQRIOBLK er en god værdi til de fleste situationer. For at udnytte den kan du sætte RU til 4 KB og Receive Window Pacing til 8.
Pacing Window for session og VR bør være så stor som muligt. Vælg den største værdi, der ikke overbelaster netværket, medfører VR-betingelser og lignende. I et testmiljø kan pacing sættes til 0 (ingen pacing) eller til den største værdi, X'3F'.
Coat-tailing styres af parameteren DELAY. DELAY-parameteren i PCCU-makroen styrer udgående coat-tailing (udgående set fra værtssystemet). DELAY-værdien i LINE-definitionen til NCP styrer indgående coat-tailing (indgående set fra værtssystemet).
DELAY-værdien afgør, hvor lang tid en PIU opbevares i køen (NCP eller VTAM), før den afsendes. Formålet med ventetiden er at øge muligheden for, at der i mellemtiden ankommer andre PIU'er, så de kan sendes samlet i et enkelt kanalprogram. Den korteste ventetid fås, ved at DELAY-værdien sættes til 0. Ud over at forbedre performance for udgående trafik skulle ændring af coat-tailing-værdien til 0 ikke have nogen mærkbar indflydelse på værtssystemet. Det vil også give en vis forbedring af performance for indgående trafik.
Der bør udvises større forsigtighed, inden DELAY ændres til 0 i NCP. Værdien kan sættes til 0, hvis NCP ikke er overbelastet, og den indgående trafik ikke består af en stor andel af små rammer (frames). En DELAY-værdi på 0 kan forbedre svartiden betydeligt, især ved let belastning og i test- og benchmark-miljøer.
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
Aspekter i forbindelse med DELAY er beskrevet i VTAM Network Implementation Guide.
MAXBFRU bør sættes til en værdi, der er to eller tre gange så stor som den største PIU-størrelse.
Sørg for, at LLC2-vinduesstørrelserne (værdier for DLC Send og Receive Window) er ens i NCP og på DB2 Connect Enterprise Edition-gatewayen. Det giver en betydelig effekt, især når serveren er DB2 Connect til AIX. Det anbefales at angive en højere værdi for Send Window end for Receive Window.
Generelt bør alle værdier for LLC-tidsfrister og -vinduer optimeres for SNA-forbindelser via Token Ring-netværk. I nogle tilfælde har det givet en seksdobling af dataoverførselshastighed og svartid.
For Token Ring-netværk bør den maksimale rammestørrelse være så stor som muligt.
Nedenstående oplysninger gengives fra IBM WSC Flash-dokument nummer 9718 (ikke oversat).
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