Gebruikershandleiding


Pooling van verbindingen

DB2 Connect Enterprise Edition-servers leveren vaak databaseverbindingen voor duizenden gelijktijdige clientopdrachten. Tijdens het tot stand brengen en verbreken van verbindingen naar de databaseserver, kunnen veel resources zijn vereist en kan de performance van zowel de databaseserver als de DB2 Connect-server negatief woren beïnvloed. Dit wordt met name duidelijk in webomgevingen waar vaak voor elk bezoek aan een webpagina een nieuwe verbinding met de databaseserver tot stand moet worden gebracht, een query moet worden uitgevoerd en een verbinding moet worden beëindigd. Om deze overhead te verminderen gebruikt DB2 Connect Enterprise Edition pooling van verbindingen, waarbij open verbindingen met de database worden onderhouden in een makkelijk toegankelijke pool.

De werking van pooling van verbindingen

Pooling van verbindingen is transparant voor toepassingen die verbinding zoeken met de host via DB2 Connect. Wanneer een toepassing verzoekt om verbreking van de verbinding met de host, verwijdert DB2 Connect de inkomende verbinding met de toepassing, maar wordt de uitgaande verbinding met de host in een pool behouden. Wanneer een nieuwe toepassing een verbinding aanvraagt, gebruikt DB2 Connect een verbinding uit de bestaande pool. Het gebruik van de reeds aanwezige verbinding vermindert niet alleen de totale verbindingstijd, maar ook de hoge CPU-verbindingskosten op de host.

Om pooling van verbindingen te gebruiken moet de volgende APAR worden toegepast op DB2 for OS/390 Versie 6.1:

     APAR PQ33473

DB2 Connect-agents hebben een actieve of een niet-actieve status. Een agent is actief wanneer deze werk uitvoert voor een toepassing. Als dit werk is voltooid, vervalt de agent in de status niet-actief in afwachting van verder werk van dezelfde of een andere toepassing. Alle niet-actieve agents worden ondergebracht in de pool voor niet-actieve agents. U kunt de grootte van de pool configureren met behulp van de configuratieparameter NUM_POOLAGENTS. Deze parameter is gelijk aan het maximumaantal niet-actieve agents dat het systeem moet behouden. Als u deze parameter op nul instelt, schakelt u de voorziening voor pooling van verbindingen uit.

DB2 Connect brengt geen verbindingen met de database tot stand zonder clientopdracht. U kunt echter wel de pool van niet-actieve agents vullen voordat er een opdracht van een client ontvangen is. De pool kan bij het opstarten worden gevuld met behulp van de configuratieparameter NUM_INITAGENTS. Deze parameter bepaalt hoeveel niet-actieve agents er moeten worden gemaakt bij het opstarten. Deze niet-actieve agents hebben aanvankelijk geen verbinding met de hostdatabaseserver.

Wanneer een client om een verbinding met de host vraagt, probeert DB2 Connect om een van de agents uit de pool te gebruiken die een verbinding hebben met de hostdatabaseserver. Als dat niet lukt, wordt gezocht naar een beschikbare agent in de niet-actieve pool. Als de pool leeg is, maakt DB2 Connect een nieuwe agent.

U kunt het maximumaantal agents dat tegelijkertijd actief kan zijn, beheren met behulp van de configuratieparameter MAX_COORDAGENTS. Als dat aantal wordt overschreden, mislukken nieuwe verbindingen met foutbericht sqlcode SQL1226. (Deze code houdt in dat het maximumaantal gelijktijdige uitgaande verbindingen is overschreden.)

Met de DB2-registervariabele DB2CONNECT_IN_APP_PROCESS kunnen toepassingen die op dezelfde machine worden uitgevoerd als DB2 Connect EE, DB2 Connect binnen het toepassingsproces uitvoeren (standaardinstelling) of een verbinding met de DB2 Connect EE-server tot stand brengen en vervolgens de hostverbinding binnen een agent uitvoeren. Voordat een toepassing pooling van verbindingen kan gebruiken, moeten verbindingen met de host vanuit de agents van de DB2 Connect EE-server worden gemaakt. Daarvoor moet DB2CONNECT_IN_APP_PROCESS dus worden ingesteld op NO.

DB2 Connect-verbindingsconcentrator

De verbindingsconcentrator-technologie van DB2 Connect biedt DB2 Connect Enterprise Edition-servers de mogelijkheid om ondersteuning te bieden voor duizenden gebruikers die gelijktijdig zakelijke transacties uitvoeren, terwijl het benodigde aantal resources op de S/390-host of AS/400-databaseservers, drastisch wordt teruggebracht. Dit doel wordt bereikt door de werkbelasting van alle toepassingen te concentreren in een veel kleiner aantal S/390-host- of AS/400-databaseserververbindingen. Dit lijkt op de functie voor pooling van verbindingen die hierboven is beschreven, maar is in feite een veel geavanceerdere benadering om het gebruik van resources te verminderen bij OLTP-toepassingen (On-line Transaction Processing) van grote omvang.

Pooling van verbindingen zorgt ervoor dat er geen nieuwe verbinding tot stand hoeft te worden gebracht als een toepassing die wordt afgesloten geen verbinding meer nodig heeft. Met andere woorden, de ene toepassing moet de verbinding verbreken voordat een andere de verbinding in de pool opnieuw kan gebruiken.

Met de verbindingsconcentrator kan DB2 Connect daarentegen een verbinding vrijmaken voor een toepassing op het moment dat een andere toepassing een transactie heeft beëindigd, zonder dat die andere toepassing de verbinding hoeft te verbreken. In essentie worden een databaseserververbinding en de bijbehorende host- en DB2 Connect-resources alleen gebruikt door een toepassing als deze een actieve transactie heeft. Op het moment dat de transactie gereed is, zijn de verbinding en de bijbehorende resources vrij voor gebruik door iedere andere toepassing waarvoor een transactie moet worden uitgevoerd.

Implementatie van de verbindingsconcentrator

In vorige versies van DB2 Connect beschikte elke actieve toepassing over een EDU (Engine Dispatchable Unit) die zowel de databaseverbinding als alle toepassingsaanvragen beheerde. Deze EDU werd over het algemeen aangeduid als coördinerende agent. Iedere coördinerende agent hield de status of context van de toepassing en de EDU bij. EDU's nemen een flinke hoeveelheid geheugen in beslag als het aantal verbindingen toeneemt, en het afwisselen van contexten tussen agents leidt tot extra overhead.

In bovenstaande architectuur bestaat er een één-op-één relatie tussen verbindingen en EDU's. Met de verbindingsconcentrator hoeft die verhouding echter niet meer één-op-één te zijn. De relatie tussen verbindingen (X) en EDU's (Y) is nu dus X >= Y.

Met de verbindingsconcentrator wordt de agent in twee delen gesplitst, een logische agent en een werkagent. Logische agents vertegenwoordigen een toepassing maar zonder te verwijzen naar een bepaalde EDU. De logische agent bevat alle gegevens en stuurblokken die een toepassing nodig heeft. Als er n toepassingen met de server zijn verbonden, zijn er ook n logische agents op de server. Werkagents zijn fysieke EDU's die toepassingsopdrachten uitvoeren, maar geen permanente verbinding hebben met welke toepassing dan ook. Werkagents gaan koppelingen aan met logische agents om transacties uit te voeren, en beëindigen die koppeling aan het einde van de transactie en gaan dan weer terug naar de beschikbare pool.

Een eenheid die logische-agentplanner heet, wijst werkagents toe aan logische agents. Beperkingen in het aantal open-bestandshandles op sommige computersystemen kunnen ertoe leiden dat er meer dan een plannersubsysteem wordt gemaakt wanneer het aantal logische agents de limiet voor bestands-handles overschrijdt.

De concentrator activeren

Als u de verbindingsconcentrator wilt gebruiken, moet u de volgende APAR toepassen op DB2 for OS/390 Versie 6.1:

     APAR PQ33473

Met de configuratieparameter MAX_LOGICAGENTS van de databasebeheerder kunt u het aantal logische agents instellen. U kunt de concentratorvoorziening activeren door de waarde voor MAX_LOGICAGENTS hoger in te stellen dan het standaardaantal. De standaardwaarde voor MAX_LOGICAGENTS is gelijk aan de waarde voor MAX_COORDAGENTS. Omdat elke toepassing één logische agent heeft, bepaalt MAX_LOGICAGENTS in feite het aantal toepassingen dat kan worden verbonden met het databasesubsysteem, terwijl MAX_COORDAGENTS het aantal inkomende verbindingen beheert dat op een gegeven moment actief is. MAX_LOGICAGENTS is een waarde tussen MAX_COORDAGENTS en 64.000. Het standaardaantal logische agents is gelijk aan MAX_COORDAGENTS.

De volgende bestaande configuratieparameters worden gebruikt om agents te configureren:

MAXAGENTS
Maximumaantal werkagents.

MAX_COORDAGENTS
Maximumaantal actieve coördinerende agents.

NUM_POOLAGENTS
Grootte van de agentpool. De agentpool bevat niet-actieve en beschikbare agents.

NUM_INITAGENTS
Oorspronkelijke aantal werkagents in de pool. Dit zijn de niet-actieve agents.

Ondersteuning voor XA-transacties

Met de architectuur van de verbindingsconcentrator kan DB2 Connect ondersteuning bieden voor nauw verbonden XA-transacties op DB2 for OS/390 en DB2 for AS/400. Net als bij andere transacties koppelt de concentrator een werkagent aan een bepaalde XA-transactie (één XID). Als de XA-transactie echter wordt afgesloten met xa_end() (vertakkingsgrens), wordt de werkagent niet vrijgegeven in de algemene pool. In plaats daarvan blijft die worker aan de desbetreffende XA-transactie gekoppeld. Wanneer er een andere toepassing aan dezelfde XA-transactie wordt toegevoegd, wordt de werkagent aan die toepassing gekoppeld.

Na een transactiegrensaanroep keert de agent weer terug naar de pool. Zo keert de agent terug naar de normale pool na xa_prepare() met alleen-lezen, xa_rollback(), xa_recover(), xa_forget(), xa_commit() of na een willekeurige XA-fout die een ROLLBACK veroorzaakt. Met Xa_end() zelf wordt alleen de transactievertakking beëindigd, en dat is niet genoeg om de koppeling met het XID te verbreken.

Voorbeelden

  1. Veronderstel een omgeving waarin 4.000 gelijktijdige verbindingen of meer nodig zijn. Een webserver die CGI-toepassingen gebruikt of een kantoorsysteem met veel desktopgebruikers kunnen dit aantal overschrijden. In deze gevallen werkt DB2 Connect uit het oogpunt van efficiëntie doorgaans als zelfstandige gateway: de database en het DB2 Connect-systeem bevinden zich daarbij op verschillende machines.

    Het DB2 Connect-serversysteem is mogelijk niet in in staat om 4.000 gelijktijdige open verbindingen te onderhouden met de databasemachine. In de meeste gevallen is het aantal transacties dat op elk willekeurig moment plaatsvindt, aanzienlijk lager dan het aantal gelijktijdige verbindingen. De systeembeheerder kan de efficiëntie van het systeem dan vergroten door de databaseconfiguratieparameters als volgt in te stellen:

         MAX_LOGICAGENTS =  4.000
         MAX_AGENTS      =  1.000
         MAX_COORDAGENTS =  1.000
         NUM_POOLAGENTS  =  1.000
    

    De concentrator houdt dan maximaal 4.000 gelijktijdige sessies open, terwijl de gateway slechts 1.000 transacties tegelijkertijd beheert.

  2. In het bovenstaande voorbeeld maken en verbreken werkagents voortdurend koppelingen met logische agents. Actieve agents die wel een verbinding met de database onderhouden maar die niet deelnemen aan een bepaalde transactie, zijn dus vrij wanneer een logische agent (toepassing) om verbinding vraagt.

    XA-transacties zijn een ander geval. In dit voorbeeld wordt waarschijnlijk dat er een TP-monitor gebruikt met een DB2 Connect-gateway en een OS/390- of AS/400-database. Wanneer een toepassing verbinding aanvraagt, wordt een niet-actieve agent aangeboden om aan dat verzoek te voldoen of wordt een nieuwe werkagent gemaakt door de concentrator. Veronderstel dat de toepassing een XA-transactie aanvraagt. Er wordt een XID gemaakt voor deze transactie en de werkagent wordt hieraan gekoppeld.

    Wanneer aan het verzoek van de toepassing is voldaan, geeft deze de opdracht xa_end() om te worden losgekoppeld van de werkagent. De werkagent blijft gekoppeld aan het XID van de transactie. De agent kan nu alleen voldoen aan verzoeken voor transacties met het bijbehorende XID.

    Op dit moment kan een andere toepassing een aanvraag doen voor een transactie die geen XA-transactie is. Zelfs als er geen andere werkagents beschikbaar zijn, kan de agent die is gekoppeld aan het XID, niet worden vrijgemaakt voor de tweede toepassing. De agent wordt als actief beschouwd. Er wordt dus een nieuwe werkagent gemaakt voor de tweede toepassing. Wanneer de tweede toepassing de transactie heeft voltooid, wordt de werkagent vrijgegeven in de beschikbare pool.

    In de tussentijd kunnen andere toepassingen die de transactie aanvragen die bij het XID van de eerste agent hoort, aan die agent worden gekoppeld en weer worden losgekoppeld, en voert de agent de toegewezen XA-transactie uit. Toepassingen die deze transactie aanvragen, worden naar deze agent gezonden als de agent vrij is.

    De werkagent wordt pas vrijgegeven in de algemene pool als er een transactiegrensaanroep wordt gegeven. (niet xa_end()). Een toepassing kan bijvoorbeeld de transactie beëindigen met xa_commit(), waarna de koppeling tussen de werkagent en het XID wordt opgeheven en de agent terugkeert naar de beschikbare pool. Vanaf dat moment kan de agent weer worden gebruikt door alle toepassingen die een aanvraag doen, of dat nu voor een nieuwe XA-transactie is of niet.

Beperkingen

Er geldt een aantal belangrijke beperkingen voor het gebruik van de gatewayconcentrator. Lees de volgende informatie goed door voordat u de verbindingsconcentrator gaat gebruiken op uw systeem.

Databasetuning

De systeemperformance wordt beïnvloed door de performance van de database van de host of de AS/400-databaseserver.

Verschillende databasebeheersystemen hebben verschillende performancekenmerken. Zo kunnen SQL-optimizers voor verschillende systemen zich binnen dezelfde toepassing anders gedragen. Raadpleeg de documentatie over de systeemperformance van uw host- of AS/400-databaseserversysteem voor meer informatie.

Voor DB2 Universal Database for AS/400 kunt u de performance wellicht verbeteren door gebruik te maken van de bindopties UR (niet-vastgelegde READ) of NC (no commit) om opname in een journaal te voorkomen.

Opmerking:Wanneer u gebruikmaakt van UR kunnen uitsluitend niet in het journaal opgenomen gegevens worden gelezen en niet worden bijgewerkt. Dit kan alleen wanneer BLOCKING is ingesteld op ALL.

Afhankelijk van de toepassingenserver en de granulatie van vergrendeling die deze biedt, kan het vergrendelingsniveau voor een query of toepassing een significante invloed hebben op de performance.

De database moet het juiste niveau voor normalisatie, effectief gebruik van indexen en een passende toewijzing van databaseruimte hebben. De performance kan ook worden beïnvloed door de gegevenstypen die u gebruikt, zoals beschreven in de volgende paragrafen.

DB2 afstemmen op OS/390

Voor TCP/IP-ondersteuning is minimaal OS/390 V1R3 vereist. OS/390 V2R5 of hoger wordt ten zeerste aangeraden.

DDF (Distributed Data Facility) is verantwoordelijk voor verbinding van gedistribueerde toepassingen met DB2 for OS/390. DDF moet worden ingesteld als een toepassingenserver. Hiertoe moet u de LU-naam van het systeem op afstand opnemen in de tabel SYSIBM.LUNAMES of de waarden LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT en USERNAMES in de tabel SYSIBM.SYSLUNAME. Voer vervolgens een DDF-update uit op de Boot Strap Data Set (BSDS). Bijvoorbeeld:

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

Voor de beste performance moet u de aanbevolen DDF-prioriteit voor adresseerbare ruimte gebruiken (enigszins lager of gelijk aan DBM1 in de werkstand COMPAT). Gebruik, indien mogelijk, RACF-caching van machtigingen in VLF en caching van V5-pakketmachtigingen. CACHEPAC=32768 is voor de meeste bewerkingen een geschikte waarde.

Omdat DDF zal proberen om verbinding te maken met VTAM, moet VTAM actief zijn op het moment dat DDF start. Hieronder vindt u een voorbeelddefinitie van VTAM APPL:

   
              SYD51TC* APPL  AUTH=(ACQ),                       X
              PARSESS=YES,                                     X
              HAVAIL=YES,                                      X
              EAS=1600,                                        X
              APPC=YES,                                        X
              DSESLIM=1024,                                    X
              DMINWNL=512,                                     X
              DMINWNR=512,                                     X
              AUTOSES=1,                                       X
              SECACPT=ALREADYV,                                X
              SRBEXIT=YES,                                     X
              SYNCLVL=SYNCPT,                                  X
              MODETAB=DB2MODET,                                X
              VPACING=63                                       X

Verwerking van inactieve threads kan in OS/390 worden geoptimaliseerd. In V3 waren maximaal 10.000 gelijktijdig verbonden clients toegestaan en in V4 en V5 25.000. In alle gevallen is het maximale aantal dat gelijktijdig actief kan zijn echter 1999. Elke werkstationclient kan verbonden blijven wanneer deze inactief is; de thread ervan wordt bij elke uitvoering van een COMMIT in een inactieve reeks geplaatst.

De DSNZPARM-parameters CMTSTAT, CONDBAT en MAXDBAT beïnvloeden de verwerking van threads. Voor de beste performance stelt u CMTSTAT in op INACTIVE en past u CONDBAT aan aan het maximumaantal verbonden DBAT's waarmee een goede performance kan worden verkregen en MAXDBAT aan het maximumaantal toegestane actieve DBAT's.

Raadpleeg het Connectivity Supplement voor uitgebreide informatie over het verbinden van DB2 for OS/390 aan een DRDA-netwerk en over de configuratie van VTM.

Gegevensconversie

Wanneer gegevens van de ene omgeving naar de andere worden overgebracht, moeten ze mogelijk worden geconverteerd. Deze conversie kan de performance beïnvloeden.

Denk hierbij aan de volgende platforms:

en de volgende typen numerieke gegevens:

Tabel 8 geeft aan wanneer conversie plaatsvindt.

Tabel 8. Gegevensconversie

 


Intel


IEEE


S/370 & S/390


OS/400


Gecomprimeerde-decimaalgegevens


Intel
IEEE
S/370/390
OS/400


Nee
Nee
Nee
Nee


Nee
Nee
Nee
Nee


Nee
Nee
Nee
Nee


Nee
Nee
Nee
Nee


Zoned decimal-gegevens


Intel
IEEE
S/370/390
OS/400


Nee
Nee
Ja
Ja


Nee
Nee
Ja
Ja


Ja
Ja
Nee
Nee


Ja
Ja
Nee
Nee


Geheel getal


Intel
IEEE
S/370/390
OS/400


Nee
Ja
Ja
Ja


Ja
Nee
Nee
Nee


Ja
Nee
Nee
Nee


Ja
Nee
Nee
Nee


Drijvende-kommagegevens


Intel
IEEE
S/370/390
OS/400


Nee
Ja
Ja
Ja


Ja
Nee
Ja
Nee


Ja
Ja
Nee
Ja


Ja
Nee
Ja
Nee

De CPU-kosten voor conversie van enkelbyte alfanumerieke gegevens zijn over het algemeen lager dan die van de conversie van numerieke gegevens (waarbij gegevensconversie vereist is).

Gegevensconversie van DATE/TIME/TIMESTAMP kost bijna evenveel als gegevensconversie van enkelbyte CHAR. Gegevensconversie van drijvende-kommagegevens (FLOATING) kost het meest. De toepassingsontwerper kan hiermee rekening houden bij het ontwerpen van een op DB2 Connect gebaseerde toepassing.

Wanneer een databasetabel een kolom met de definitie 'FOR BIT DATA' bevat, hoeven de alfanumerieke gegevens die worden overgebracht van de toepassing naar de database niet te worden geconverteerd. U kunt hiervan gebruikmaken wanneer u gegevens archiveert op de host of de AS/400-databaseserver.

Gegevenstypen voor alfanumerieke gegevens

Alfanumerieke gegevens kunnen het gegevenstype CHAR of VARCHAR hebben. Welke gegevens efficiënter zijn, hangt af van de lengte van de gegevens in het veld:

Netwerktuning

De beste manier om de algemene performance in een gedistribueerde databaseomgeving te verbeteren, is het elimineren van vertragingen vanaf het netwerk. Over het algemeen vinden netwerkbeheerders een netwerk efficiënter wanneer het zoveel mogelijk gegevens verzamelt tussen transmissies. Dit uitgangspunt werkt niet bij toepassingen zoals gedistribueerde databases omdat hierdoor vertragingen in het netwerk ontstaan. De eindgebruiker zal de efficiëntie van een netwerk niet opmerken, de vertragingen echter wel.

De meeste netwerkapparatuur heeft vertragingsparameters waarvan de meeste op standaardwaarden zijn ingesteld die erg slecht zijn voor gedistribueerde databases. Voor het verbeteren van de performance moet u deze parameters opzoeken en zo mogelijk instellen op nul. Daarnaast moet worden gecontroleerd of de bufferomvang op het apparaat groot genoeg is om herhaald verzenden vanwege verloren gegevens te voorkomen. UNIX-systemen hebben bijvoorbeeld een wachtrijlengte van 32 voor Transmit of Receive. Stel de wachtrijlengte in op 150 voor betere resultaten. Een vergelijkbare parameter voor DLC-instellingen is Receive Depth. Deze moet ook 150 zijn.

De parameter IOBUF is op de meeste sites te laag ingesteld. Meestal is deze ingesteld op 150, maar de praktijk wijst uit dat een waarde van 3992 het best werkt wanneer er grote hoeveelheden gegevens worden verplaatst, vooral voor kanaalverbindingen zoals ESCON of 3172.

Voor SNA-verbindingen moet Mode Profile voor alle werkstationsoftware worden ingesteld op 63. In het algemeen moeten de waarden voor transmissiesnelheid voor ontvangst worden ingesteld op de hoogste waarde. De parameters VPACING en PACING in de instructie DB2 APPL en de PU/LU voor het werkstation in een geschakelde hoofdwerkstand moeten dus worden ingesteld op 63. Hierdoor kan de omvang van berichtenstromen progressief toenemen voordat de afzender moet wachten op een respons.

Op een LAN-systeem kan het DLC- of LLC-vensterformaat voor verzending en ontvangst veel invloed hebben op de performance. De verzendwaarde moet worden ingesteld op zeven of meer en voor de meeste configuraties werkt een ontvangstwaarde van vier of minder het best.

Wanneer u gebruikmaakt van Ethernet moet u de segmentomvang van TCP instellen op 1500 bytes. Op een Token-Ring netwerk of een FDDI-netwerk moet deze waarde 4400 bytes zijn. Als u gebruikmaakt van een ESCON-adapter met TCP/IP moet de segmentgrootte altijd 4096 zijn.

Tenslotte moet voor TCP/IP-netwerken de bufferomvang voor TCP Send en Receive hoger worden ingesteld dan 32768. Over het algemeen is 65536 de beste waarde.
Opmerking:Het tot stand brengen van een verbinding van de gateway naar de server (uitgaande verbinding) is duurder dan het tot stand brengen van een verbinding van een client naar de gateway (inkomende verbinding). In een omgeving waar duizenden clients vaak een verbinding met de server via de gateway maken en verbreken, wordt een groot deel van de verwerkingstijd besteed aan het tot stand brengen van uitgaande verbindingen. DB2 Connect zorgt voor pooling van verbindingen via TCP/IP. Wanneer een client verzoekt om verbreking van de verbinding met de server, dan verwijdert de gateway de uitgaande verbinding met de client, maar wordt de uitgaande verbinding met de server in een pool behouden. Wanneer er een nieuwe client in de gateway komt die verzoekt om een verbinding, geeft de gateway een bestaande verbinding vanuit de pool. Op die manier wordt de totale verbindingstijd verkort en wordt op de hoge CPU-verbindingskosten op de server bespaard.

Raadpleeg de Administration Guide voor meer informatie over pooling van verbindingen onder DB2.

In de volgende tabel wordt een overzicht gegeven van methoden voor het verbeteren van de netwerkperformance.
Zoeken naar Voorbeeld Instelling Opmerkingen
Doelbewuste vertragingen Vertragings-parameters op netwerkapparaten Ingesteld op 0. Standaardwaarden zijn meestal hoger.
Buffers IOBUF-parameter Instellen tot 3992. Vooral nuttig voor een ESCON- of andere kanaaladapter.
RUSIZE Optimale grootte is 4096. Instelling van RUSIZE en RQRIOBLK op dezelfde grootte geeft mogelijk de beste performance.
Transmissiesnelheid VPACING, PACING en Mode Profiles moeten worden ingesteld op 63. Gebruik aanpasbare transmissiesnelheid waar mogelijk.
Adapterinstellingen Wachtrijlengte voor verzenden/ ontvangen Aanbevolen waarde is 150. Standaardwaarde is gewoonlijk 32.
DLC-vensters op SNA Stel de windowgrootte voor verzenden in op hoog (>7). Stel de windowgrootte voor ontvangen in op laag (bijvoorbeeld 1) en test en verhoog dit herhaaldelijk om de ideale waarde te vinden. Elk logisch apparaat voegt vertragingen toe. Vereenvoudig de netwerktopologie zoveel mogelijk.
TCP-instellingen Grootte van segmenten 1500 op Ethernet, 4400 op Token-Ring en FDDI. ESCON-adapters die worden gebruikt voor TCP/IP, moeten ingesteld zijn op 4096.
Grootte van zend/ontvang-ruimte Moeten beide 64 kB zijn. Standaard is alleen 8192 voor Windows. Kan worden ingesteld in het register van Windows.

Netwerkhardware

De volgende overwegingen hebben betrekking op de hardware:

Rivaliteit voor systeemresources

De performance kan verslechteren wanneer veel taken binnen het systeem tegelijkertijd systeemresources opvragen. Houd rekening met het volgende:

Performanceproblemen oplossen

Wanneer gebruikers van DB2 Connect tijdens lange query's vanaf de host of de AS/400-servers worden geconfronteerd met lange responstijden moeten de volgende gebieden worden onderzocht om de mogelijke oorzaak van het performanceprobleem op te sporen:

  1. Controleer voor query's die resulteren in het terugzenden van omvangrijke gegevensblokken vanaf de host of de AS/400-server (meestal 32 kB aan gegevens of meer), of de DBM-configuratieparameter (Database Manager) RQRIOBLK is ingesteld op 32767. U kunt hiervoor de Opdrachtregelinterface (CLP) gebruiken:
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. Wanneer VTAM wordt gebruikt bij de verbinding met de host of de AS/400-server, controleert u de configuratie "switched major node" op de waarde van de parameter PACING. Controleer de communicatie-instellingen van het "LU 6.2 Mode Profile" op de definitie van de werkstand IBMRDB op het DB2 Connect-werkstation. Controleer in deze definitie of de waarde van de parameter "Receive pacing window" kleiner of gelijk is aan de waarde PACING die is gedefinieerd op VTAM. Een algemene waarde voor "Receive pacing window" op het DB2 Connect-werkstation en "PACING" op VTAM is 8.
  3. Controleer of de maximale RU-grootte in de werkstanddefinitie IBMRDB op een passende waarde is ingesteld. Voor verbindingen met gebruik van Token-Ring hardware wordt minstens 4 kB aangeraden. Bij verbindingen met Ethernet-hardware kan de maximale framegrootte van 1536 bytes voor Ethernet een beperkende factor zijn.
  4. Raadpleeg de VTAM-beheerder in uw omgeving om er zeker van te zijn dat VTAM gebruikmaakt van "aanpasbare transmissiesnelheid" in de LU-LU-sessies met uw DB2 Connect-werkstation.


[ Begin van pagina | Vorige pagina | Volgende pagina | Inhoud | Trefwoordenregister ]