Dette avsnittet inneholder andre nyttige tips om SNA-ytelsestilpassing og tips om bruk sammen med DB2 Connect.
Ytelsesegenskapene for DB2 Connect er at det først og fremst bruker prosessoren og utfører svært få I/U-operasjoner. Generelt sett er det slik at jo raskere prosessorhastigheten er, jo raskere kjører DB2 Connect. DB2 Connect utnytter SMP-prosessorkonfigurasjonene maksimalt.
En rask DB2 Connect Enterprise Edition-tjener kan håndtere en SQL-forespørsel med svar på mindre enn fem millisekunder, ikke inkludert klienttiden, nettverkstiden og behandlingstiden på verts- eller AS/400-tjeneren. En enkel SQL-setning eller spørring med et par datarader kan bli fullført på mindre enn 0,1 sekund (fra klienten til verts- eller AS/400-tjeneren og tilbake).
Hvis det er flere enn fire eller fem SQL-setninger i en spørring, kan bruk av lagrede prosedyrer sikre høy OLTP-ytelse og hindre økninger i antall låsekonflikter på grunn av nettverksforsinkelser mellom SQL-setningene.
Ytelsesproblemer blir vanligvis forårsaket av typen vertstilknytning som brukes, nettverksruting- og justeringsegenskaper og applikasjonsutformingen. Du finner generell informasjon om DB2 Connect-ytelse i Andre informasjonskilder om DB2 Connect-ytelse.
Du får sannsynligvis best DB2 Connect-ytelse hvis du bruker en av disse typene nettverkstilknytning:
Det siste alternativet anbefales ikke - les nedenfor.
Vi anbefaler at du bruker ESCON-kanaltilkoblingskort for AIX, Windows NT eller Windows 2000 når du skal koble deg til vertsmaskinen. IBM 3172 modell 3 og 2216 fungerer også bra, men de har lavere hastighet enn ESCON.
Når du bruker AIX med ESCON-kort, må du ta i bruk PTFene for MPC (Multi Path Channel). Uten disse PTFene kan SNA ESCON-styreprogrammet for AIX gi dårligere ytelse. Du finner flere opplysninger om dette i MPC-støtte for SNA over ESCON. Du finner også flere opplysninger på: http://www.networking.ibm.com.cms/cmsnew01.html
I Justere DB2 Connect-tilkoblinger via NCP finner du en kontrolliste over hvilke kommunikasjonstjener-, NCP- og VTAM-parametere du kan justere for å optimalisere DB2 Connect-ytelsen. Alle anbefalingene som ikke gjelder spesielt for NCP, gjelder alle typene DB2 Connect- og klient/tjener-tilknytninger.
OSA-2-kortet på System/390 gir kanskje ikke like stor hastighet som en 3272 modell 3 hvis det blir utført mange små transaksjoner, siden det håndterer færre rammer per sekund. Du finner flere opplysninger om de nyeste forbedringene i Informasjon om OSA-2-forbedringer.
3145 med NCP blir vanligvis tilpasset for en bestemt eksisterende nettverkstrafikk. Derfor er det ikke sikkert at det fungerer like bra for klient/tjener-applikasjoner for database. De fleste DB2 Connect-ytelsesproblemene skyldes tidsforsinkelsen mellom NCP og VTAM og/eller mellom NCPer. Les Justere DB2 Connect-tilkoblinger via NCP, som inneholder en kontrolliste for justering.
Generelt sett anbefaler vi at du ikke bruker 3174-terminalstyreenheter fordi pakkestørrelsen (RU-størrelsen) på 256 byte er for liten. Du må ha 3174 mikrokodenivå C hvis du ønsker støtte for uavhengig logisk enhet (LU) for APPC-databasetilkoblinger. Noen kort som tilsvarer OEM 3174, kan ha liknende avhengighetsbegrensninger.
Hvis du har støtte for MPC (Multi Path Channel) for SNA over ESCON, kan et system som kjører IBM eNetwork Communications Server, bruke et ESCON-kort til å opprette en MPC-linkstasjon til vertsmaskinen. MPC er vanligvis raskere enn CDLC fordi:
Tester har vist at en MPC-link kan være opptil tre ganger raskere enn en ESCON CDLC-link (CDLC=Channel Data Link Control) med en IOBUF-størrelse på mindre enn 1 kB. AIX SNA MPC krever ESCON og MVS VTAM V4R4 eller nyere og funksjonskoden 4024 for Communications Server for AIX (5765-652). Windows NT-systemer må bruke IBM eNetwork Communications Server for Windows NT versjon 6.
Du må ha disse PTFene for MPC for Communications Server for AIX:
APAR # PTF # 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
Dette er et eksempel på en vanlig nettverkskonfigurasjon:
Figur 8. SNA-nettverksscenario med DB2 Connect Enterprise Edition-portner
![]() |
Dette scenariet legger mest vekt på hastigheten og svartiden mellom verts- eller AS/400-databasetjeneren og DB2 Connect Enterprise Edition-portneren og ulike parametere som kan påvirke dette.
Anbefalt rekkefølge for endringene:
1 - DELAY på PCCU-makro* 2 - DLC/LLC-justering* 3 - PIU-størrelse* 4 - Endringer i taktvindu* 5 - DELAY på LINE-makro* 6 - MAXBFRU-endringer 7 - Rammestørrelser for lokalnett * Hastighetsforbedringen kan være stor
RU-størrelsen på verts- og DB2 Connect-tjeneren bør maksimeres. Det vil si at RU-størrelsen bør være stor nok til å inneholde API-overføringen (både SEND- og RECEIVE-data for transaksjonen der det er mulig) for å minimere antall ganger dataene må passere VTAM-programstakken. Nettverksrammestørrelsen kan også begrense den maksimale RU-størrelsen hvis du ikke ønsker RU-segmentering.
Du bør definere DB2 Connect-blokkstørrelsen (RQRIOBLK) og RU- og taktverdien slik at RU * takten >= RQRIOBLK. Standardstørrelsen for RQRIOBLK på 32 kB er en bra verdi for de fleste situasjoner, og for å utnytte dette bør du sette RU = 4 kB og mottaksvindutakten til 8.
Sesjons- og VR-taktvinduene (pacing windows) bør maksimeres. Du bør bruke den største verdien som ikke fører til overbelastning på nettverket eller at VR holdes etc. I et testmiljø bør du sette takten til 0 (ingen takt) eller sette den til maksimumsverdien X'3F'.
Forsinkelsen blir kontrollert av DELAY-parameteren. DELAY-parameteren i PCCU-makroen kontrollerer den utgående forsinkelsen (utgående i forhold til vertsmaskinen). DELAY-verdien i LINE-definisjonssetningen for NCP kontrollerer den innkommende forsinkelsen (innkommende i forhold til vertssystemet).
DELAY-verdien bestemmer hvor lenge en PIU blir holdt tilbake i køen (NCP eller VTAM) før den blir overført. Formålet med denne ventingen er å øke muligheten for at andre PIUer blir mottatt i mellomtiden, og at disse kan overføres i et enkelt kanalprogram. Hvis du vil ha minst mulig venting, setter du DELAY-verdien til 0. Hvis du endrer verdien for den utgående forsinkelsen til 0, bør det ikke ha noen merkbar innvirkning på vertsmaskinen med unntak av forbedret ytelse for utgående trafikk. Ytelsen for inngående trafikk kan også bli noe forbedret.
Vær litt forsiktig med å endrer DELAY-verdien på NCP til 0. Verdien kan settes til 0 hvis NCP ikke er overbelastet og den innkommende trafikken ikke har en stor andel av små rammer. Hvis du setter DELAY-verdier til 0, kan svartiden bli betydelig forbedret, spesielt under liten belastning eller i test-/ytelsestestmiljø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
Du finner flere opplysninger om bruken av DELAY-parameteren i VTAM Network Implementation Guide.
MAXBFRU-verdien bør settes til en verdi som er to eller tre ganger så stor som den største PIU-størrelsen.
Kontroller at LLC2-vindusstørrelsene (størrelsen på sende- og mottaksvinduet for DLC) mellom NCP og DB2 Connect Enterprise Edition-portneren er like. Dette har en betydelig effekt, spesielt når tjeneren er DB2 Connect for AIX. Det anbefales at størrelsen på sendevinduet ikke settes høyere enn størrelsen på mottaksvinduet.
Generelt sett bør LCC2-klokkene/-vinduene optimaliseres for SNA-tilkoblinger over token-ring. I enkelte tilfeller førte denne endringen til en seksdoblet forbedring i hastigheten og svartiden.
Den maksimale rammestørrelsen for token-ring bør være så stor som mulig.
Denne informasjonen er hentet fra IBM WSC Flash-dokumentnummer 9718.
TITTEL: WSC FLASH 9718: OSA-2 FORBEDRINGER TILGJENGELIG DOKUMENT-ID G023691 UKLASSIFISERT Forbedringer for OSA-2 SNA (Open Systems Adapter 2 Systems Network Architecture) blir gjort tilgjengelig tidligere enn det som har vært annonsert. Forbedringene omfatter: o SNA/APPN-forbedringer for OS/390, MVS/ESA, VM/ESA og VSE/ESA - Bedre tilgjengelighet: belastningsbalansering, overflødighet og overflyt - Bedre tilkoblingsmuligheter: utvidet støtte for fysiske enheter (PU) (fra 255 fysiske enheter per port til 2047 fysiske enheter per port) o Støtte for ACF/VTAM for VSE/ESA-nettverk MERK: Disse forbedringene gjelder ikke OSA-1.
BELASTNINGSBALANSERING, OVERFLØDIGHET OG OVERFLYT ________________________________________ BELASTNINGSBALANSERING: Nå kan du definere en enkelt MAC-adresse for tilkoblede fysiske enheter (PU) av typen OSA-2 SNA/APPN, selv om tilkoblingene bruker flere fysiske porter. Denne støtten er bare tilgjengelig for Token-Ring og FDDI (source-route bridged environments). Antall sesjoner som blir opprettet via en port, blir overvåket og brukersesjonsinnlastingene blir jevnt fordelt på portene som er konfigurert likt. OVERFLØDIGHET: Nå kan du konfigurere en sekundær bane mellom arbeidsstasjonen på lokalnettet og vertssystemet. Hvis hovedbanen blir utilgjengelig, mottar den sekundære banen lokalnettrafikken. Dette gjør systemet mer tilgjengelig og forenkler nettverksstyringen. OVERFLYT: Brukersesjoner flyter gjennom den primære OSA-2-porten helt til sesjonskapasiteten er nådd. Andre brukersesjoner flyter automatisk til den neste OSA-2 porten. Siden alle brukerarbeidsstasjonene blir konfigurert likt, blir nettverksadministrasjonen forenklet og nettverket blir mer fleksibelt. Nye brukere kan tilføyes uten at det oppstår noen avbrytelse. PTFer for OSA/SF gir støtte for belastningsbalansering, overflødighet og overflyt på denne måten: o OS/390 og MVS - OW20205/UW34618 03/31/97 o VM/ESA - OW23952/UW37028 03/31/97 o VSE/ESA - Følger med VSE/ESA V2.2.1 04/29/97
UTVIDET STØTTE FOR FYSISKE ENHETER (PU) (VIA OSA/SF): __________________________________________________ Arkitekturen er endret til å tillate maksimalt 2047 PUer per fysisk port som skal defineres for OSA-2 Ethernet-, Token-Ring- og FDDI-funksjoner i stedet for det gjeldende antallet med 255 PUer per port. Denne forbedringen er tilgjengelig for funksjoner som er installert, samt nye installasjoner. Den reelle tilkoblingsmulighetene kan variere etter arbeidsbelastningen. PTFer for OSA/SF gir utvidet støtte for fysiske enheter (PU) på denne måten: o OS/390 og MVS - OW23429/UW37210 03/31/97 o VM/ESA - OW24952/UW37028 03/31/97 o VSE/ESA - PQ03091/UQ04224 04/29/97 PTFer for ACT/VTAM gir utvidet støtte for fysiske enheter (PU) på denne måten: o ACF/VTAM for OS/390 og 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-STØTTE _____________________ VSE/ESA versjon 2, utgave 2.1 gir støtte for OSA-2 og OSA/SF. Denne annonseringen av VSE/ESA-støtte oppfyller Statement of General Direction i Hardware Announcement 196-194 og Hardware Announcement 196-193 fra 10. September 1996. OSA-2-funksjonen gir ACF/VTAM for VSE/ESA-vertsapplikasjoner direkte tilgang til lokalnett med Ethernet, Token-Ring og FDDI og LAN-emuleringsnettverk som er Asynchronous Transfer Mode (ATM) Forum-kompatible.
OSA/SF er tilgjengelig o som et ikke-eksklusivt element i OS/390 utgave 1 eller nyere (5645-001) o som et separat programprodukt, S/390 Open Systems Adapter Support Facility versjon 1, utgave 2 for MVS/ESA 4.3 eller nyere (5655-104) o som en funksjon i VM/ESA versjon 2, utgave 2.0 (5654-030) o som en komponent i VSE Central Functions 6.1.1 i VSE/ESA versjon 2, utgave 2.1 (5690-VSE). MER INFORMASJON ________________ Annonseringene 297-043, 297-040