DB2 Connect Enterprise Edition-tjenere gir ofte databasetilkoblinger til tusenvis av samtidige klientforespørsler. Det kan kreve veldig mye ressurser å opprette og vedlikeholde tilkoblinger til databasetjeneren, noe som reduserer ytelsen til både databasetjeneren og DB2 Connect-tjeneren. Dette gjelder spesielt i web-miljøer der du må opprette en ny tilkobling til databasetjeneren, utføre en spørring og avslutte en tilkobling hver gang du besøker en web-side. For å redusere denne behandlingen bruker DB2 Connect Enterprise Edition tilkoblingsgrupper for å vedlikeholde åpne tilkoblinger til databasen i en gruppe som er lett tilgjengelig.
Tilkoblingsgrupper er transparente for applikasjoner som kobler seg til vertsmaskinen gjennom DB2 Connect. Når en applikasjon ber om å bli koblet fra vertsmaskinen, avslutter DB2 Connect den innkommende tilkoblingen til applikasjonen, men den beholder den utgående tilkoblingen til vertsmaskinen i en gruppe. Når en ny applikasjon ber om en tilkobling, bruker DB2 Connect en tilkobling fra den eksisterende gruppen. Ved å bruke den eksisterende tilkoblingen reduseres både den totale tilkoblingstiden og de høye CPU-tilkoblingskostnadene på vertsmaskinen.
Hvis du bruker tilkoblingsgrupper, må denne APARen bli tatt i bruk for DB2 for OS/390 versjon 6.1:
APAR PQ33473
DB2 Connect-agenter kan ha to statuser: uvirksom eller aktiv. En agent er aktiv når den utfører arbeid for en applikasjon. Når dette arbeidet er fullført, får agenten statusen uvirksom mens den venter på mer arbeid fra den samme eller en annen applikasjon. Alle uvirksomme agenter blir holdt samlet i det som blir kalt et uvirksomt agentområde. Du kan konfigurere størrelsen for dette området ved hjelp av konfigurasjonsparameteren NUM_POOLAGENTS. Denne parameteren angir det maksimale antallet uvirksomme agenter du vil at systemet skal vedlikeholde. Hvis du setter denne parameter til null, er det det samme som å slå av funksjonen for tilkoblingsgrupper.
DB2 Connect oppretter ikke tilkoblinger til databasen før den mottar den første klientforespørselen. Du kan imidlertid fylle opp området med uvirksomme agenter før noen klienter sender en forespørsel, hvis du vil. Du kan fylle opp området ved oppstart ved hjelp av konfigurasjonsparameteren NUM_INITAGENTS. Denne parameteren bestemmer hvor mange uvirksomme agenter som kan opprettes ved oppstart. Disse uvirksomme agentene har ikke noen tilkoblinger til vertsdatabasetjeneren i utgangspunktet.
Når en klient ber om en tilkobling til vertsmaskinen, prøver DB2 Connect å få en av agentene i området som har en tilkobling til vertsdatabasetjeneren. Hvis det ikke lykkes, prøver den å finne en tilgjengelig agent i det uvirksomme området. Hvis området er tomt, oppretter DB2 Connect en ny agent.
Du kan kontrollere det maksimale antallet agenter som kan være aktiv samtidig, ved hjelp av konfigurasjonsparameteren MAX_COORDAGENTS. Når tallet blir overskredet, mislykkes nye tilkoblinger med SQL-feilkoden SQL1226. (Denne koden betyr at det maksimale antallet samtidige, utgående tilkoblinger er overskredet.)
DB2-registervariabelen DB2CONNECT_IN_APP_PROCESS tillater at applikasjoner som kjører på den samme maskinen som DB2 Connect EE, enten kjører DB2 Connect i applikasjonsprosessen, med standard kjøremønster, eller at de kobler seg til DB2 Connect EE-tjeneren, og deretter kjører vertstilkoblingen i en agent. Hvis en applikasjon skal bruke tilkoblingsgrupper, må tilkoblingene til vertsmaskinen utføres fra en av agentene på DB2 Connect EE-tjeneren, og derfor må DB2CONNECT_IN_APP_PROCESS være satt til NO.
Med tilkoblingskonsentratoren til DB2 Connect kan DB2 Connect Enterprise Edition-tjenere gi støtte til tusenvis av brukere som utfører forretningstransaksjoner samtidig, mens ressursene som kreves på S/390-verts- eller AS/400-databasetjenerne, blir drastisk redusert. Konsentratoren konsentrerer arbeidsbelastningen fra alle applikasjonene i et mye mindre antall tilkoblinger med S/390-verts- eller AS/400-databasetjenere. Den har likhetstrekk med tilkoblingsgruppefunksjonen som er beskrevet ovenfor, men konsentratoren er en enda mer avansert måte å redusere ressursbruken på for OLTP-applikasjoner (OLTP=On-line Transaction Processing) som behandler svært store volumer.
Med tilkoblingsgrupper slipper du kostnaden ved å opprette en tilkobling når en applikasjon avslutter en tilkobling den ikke behøver lenger. En applikasjon må med andre ord frakobles før en annen kan bruke en gruppetilkobling.
Tilkoblingskonsentratoren tillater derimot at DB2 Connect gjør en tilkobling tilgjengelig så snart en annen applikasjon har fullført en transaksjon, og krever ikke at den andre applikasjonen frakobles. I all hovedsak bruker en applikasjon bare en databasetjenertilkobling og de tilknyttede vertsmaskin- og DB2 Connect-ressursene mens den har en aktiv transaksjon. Så snart transaksjonen er ferdig, kan en annen applikasjon som skal utføre en transaksjon, bruke tilkoblingen og de tilhørende ressursene.
I tidligere versjoner av DB2 Connect hadde alle de aktive applikasjonene en EDU (Engine Dispatchable Unit) som administrerte databasetilkoblingen og eventuelle applikasjonsforepørsler. Denne EDUen ble også kalt en koordinatoragent. Hver enkelt koordinatoragent sporet statusen eller konteksten for applikasjonen og EDUen. Hver enkelt EDU bruker mye minne når antall tilkoblinger øker, og kontekstveksling mellom agentene fører til ekstra behandling.
I arkitekturen ovenfor er det et en-til-en-forhold mellom tilkoblinger og EDUer. Tilkoblingskonsentratoren tillater derimot et mange-til-en-forhold mellom tilkoblinger og EDUer. Det vil si at forholdet mellom tilkoblinger (X) og EDUer (Y) nå er X >= Y.
Tilkoblingskonsentratoren deler agentene inn i to typer, en logisk agent og en arbeidsagent. Logiske agenter representerer en applikasjon, men uten referanse til en bestemt EDU. Den logiske agenten inneholder alle opplysningene og kontrollerer blokkene som en applikasjon trenger. Hvis det er n applikasjoner tilkoblet tjeneren, er det n logiske agenter på tjeneren. Arbeidsagenter er fysiske EDUer som utfører applikasjonsforespørsler, men som ikke er permanent koblet til noen applikasjon. Arbeidsagenter kobler seg til logiske agenter for å utføre transaksjoner, og ved transaksjonsgrensen kobler de seg fra de logiske agentene og returnerer til det tilgjengelige området.
Planleggingsfunksjonen for den logiske agenten tildeler arbeidsagenter til logiske agenter. Begrensninger på antall åpne filreferanser på bestemte dataplattformer kan føre til flere planleggingsfunksjoner når antall logiske agenter overskrider filreferansegrensen.
Hvis du skal bruke tilkoblingskonsentratoren, må denne APARen bli tatt i bruk for DB2 for OS/390 versjon 6.1:
APAR PQ33473
Konfigurasjonsparameteren MAX_LOGICAGENTS for databasesystemet definerer det maksimale antallet logiske agenter. Du kan aktivere konsentratorfunksjonen ved å definere en høyere verdi for MAX_LOGICAGENTS enn standardverdien. Standardverdien for MAX_LOGICAGENTS tilsvarer verdien for MAX_COORDAGENTS. Siden hver enkelt applikasjon har en logisk agent, kontrollerer MAX_LOGICAGENTS i praksis antall applikasjoner som kan kobles til databaseforekomsten, mens MAX_COORDAGENTS kontrollerer antall innkommende tilkoblinger som kan være aktive om gangen. MAX_LOGICAGENTS henter et numerisk verdiområde fra MAX_COORDAGENTS opptil 64000. Standardantallet logiske agenter er lik MAX_COORDAGENTS.
Flere eksisterende konfigurasjonsparametere blir brukt til å konfigurere agenter. Disse parameterne er:
Arkitekturen til tilkoblingskonsentratoren tillater at DB2 Connect gir DB2 for OS/390 and DB2 for AS/400 støtte for nært tilkoblede XA-transaksjoner. Konsentratoren knytter en arbeidsagent til en bestemt XA-transaksjon (enkel XID), slik den gjør for alle transaksjoner. Hvis XA-transaksjonen derimot blir avsluttet av xa_end() (grengrensen), blir ikke arbeidsagenten frigitt til det generelle området. I stedet forblir arbeidsagenten tilknyttet den bestemte XA-transaksjonen. Når en annen applikasjon knytter seg til den samme XA-transaksjonen, blir arbeidsagenten koblet til applikasjonen.
Ved et transaksjonsgrensekall blir agenten returnert til området. For eksempel: xa_prepare() bare for lesing, xa_rollback(), xa_recover(), xa_forget(), xa_commit() eller en hvilken som helst XA-feil som fører til tilbakestilling, returnerer agenten til det vanlige området. Xa_end() avslutter bare transaksjonsgrenen, og det er ikke nok til å avslutte tilknytningen til XIDen.
Det er ikke sikkert at DB2 Connect-tjeneren klarer å vedlikeholde 4000 samtidige åpne tilkoblinger til databasemaskinen. I de fleste tilfeller er antall transaksjoner som blir utført på et bestemt tidspunkt, betydelig færre enn antall samtidige tilkoblinger. Den systemansvarlige kan maksimere effektiviteten på systemet ved å definere disse konfigurasjonsparameterne for databasen:
MAX_LOGICAGENTS = 4000 MAX_AGENTS = 1000 MAX_COORDAGENTS = 1000 NUM_POOLAGENTS = 1000
Konsentratoren holder opptil 4000 sesjoner åpne samtidig, selv om portneren bare kan administrere 1000 transaksjoner om gangen.
Med XA-transaksjoner er det litt annerledes. I dette eksempelet kan vi gå ut fra at det blir brukt en TP-overvåker sammen med en DB2 Connect-portner og en OS/390- eller AS/400-database. Når en applikasjon ber om en tilkobling, ber konsentratoren en inaktiv agent om å behandle forepørselen, eller så oppretter den en ny arbeidsagent. La oss gå ut fra at applikasjonsforespørselen er en XA-transaksjon. Det blir opprettet en XID for denne transaksjonen og arbeidsagenten blir knyttet til den.
Når applikasjonsforespørselen er behandlet, utsteder den en xa_end() og kobler fra arbeidsagenten. Arbeidsagenten forblir tilknyttet XIDen for transaksjonen. Nå kan den bare behandle forespørsler for transaksjoner med den tilknyttede XIDen.
På dette tidspunktet kan en annen applikasjon sende en forespørsel om en ikke-XA-transaksjon. Selv om det ikke er noen andre tilgjengelige arbeidsagenter, blir ikke agenten som er tilknyttet XIDen, gjort tilgjengelig for den andre applikasjonen. Den blir betraktet som aktiv. Det blir opprettet en ny arbeidsagent for den andre applikasjonen. Når den andre applikasjonen fullfører transaksjonen, blir arbeidsagenten frigitt til det tilgjengelige området.
I mellomtiden kan andre applikasjoner som ber om transaksjonen som er knyttet til den første agentens XID, koble seg til og fra denne agenten, som utfører den reserverte XA-transaksjonen for dem. En applikasjon som ber om denne bestemte transaksjonen, blir sendt til denne arbeidsagenten hvis den er ledig.
Arbeidsagenten blir ikke frigitt tilbake til det generelle området før en applikasjon utsteder et transaksjonsgrensekall (ikke xa_end()). En applikasjon kan for eksempel avslutte transaksjonen med xa_commit(), der arbeidsagenten kobler seg fra XIDen og returnerer til det tilgjengelige området. Nå kan en applikasjon som ber om det, bruke den for enten XA- eller ikke-XA-transaksjoner.
Det er flere viktige begrensninger på bruken av portnerkonsentratoren. Les all informasjonen nedenfor før du prøver å bruke tilkoblingskonsentratoren på systemet.
Systemytelsen blir påvirket av ytelsen til databasen på verts- eller AS/400-databasetjeneren.
De ulike databasesystemene har ulike ytelsesfunksjoner. SQL-optimalisatorer på ulike systemer kan for eksempel oppføre seg forskjellig med den samme applikasjonen. Du finner flere opplysninger om dette i ytelsesdokumentasjonen for verts- eller AS/400-databasetjeneren.
For DB2 Universal Database for AS/400 kan du forbedre ytelsen ved å bruke bindingsalternativene Ikke-iverksatt lesing (UR) eller Ingen iverksetting (NC) for å unngå journalføring.
Merk: | Når du bruker UR, kan data som ikke er journalført, bare leses, ikke oppdateres, og bare hvis blokking er satt til ALL. |
Avhengig av applikasjonstjeneren og hvilken inndelingsgrad (granularity) den bruker for låsing, kan isolasjonsnivået som blir brukt for en spørring eller applikasjon, ha stor innvirkning på ytelsen.
Databasen bør ha riktig normaliseringsnivå, effektiv bruk av indekser og riktig tildeling av databaseplass. Datatypene du bruker, kan også ha innvirkning på ytelsen, slik det er beskrevet nedenfor.
OS/390 V1R3 er minimumskravet for TCP/IP-støtte. Vi anbefaler på det sterkeste at du bruker OS/390 V2R5 eller nyere.
DDF (Distributed Data Facility) er ansvarlig for å koble distribuerte applikasjoner til DB2 for OS/390. DDF bør konfigureres som en applikasjonstjener. Dette kan du gjøre ved å legge LU-navnet på det fjerntliggende systemet inn i tabellen SYSIBM.LUNAMES eller ved å legge verdiene LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT og USERNAMES inn i tabellen SYSIBM.SYSLUNAME. Deretter utfører du en DDF-oppdatering av BSDS (Boot Strap Data Set). For eksempel:
DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001
For å få best mulig ytelse bør du bruke den anbefalte prioriteringen for DDF-adresseområdet (litt lavere enn eller lik DBM1 hvis du er i modusen COMPAT). Bruk RACF-hurtigbufring av autorisasjoner i VLF og hurtigbufring av V5-pakkeautorisasjoner hvis du kan. Verdien CACHEPAC=32768 er nok for de fleste operasjoner.
Siden DDF vil prøve å koble seg til VTAM, må VTAM være aktiv når DDF starter. Dette er et eksempel på en VTAM APPL-definisjon:
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
Du kan optimalisere behandlingen av inaktive tråder på OS/390. I V3 kan du ha opptil 10 000 klienter tilkoblet samtidig, og opptil 25 000 i V4 og V5. I alle tre tilfellene er imidlertid 1999 det maksimale antallet klienter som kan være aktive samtidig. Hver enkelt arbeidsstasjonsklient kan forbli tilkoblet mens den er inaktiv. Tråden til klienten blir lagt i en inaktiv kjede ved hver iverksetting.
DSNZPARM-parameterne CMTSTAT, CONDBAT og MAXDBAT påvirker trådbehandlingen. For å få best mulig ytelse bør du sette CMTSTAT til INACTIVE, CONDBAT til det maksimale antallet tilkoblede DBATer som gir god ytelse, og MAXDBAT til det maksimale antallet aktive DBATer.
Hvis du ønsker mer fullstendig informasjon om tilkobling av DB2 for OS/390 i et DRDA-nettverk, inkludert VTAM-konfigurasjonen, leser du Connectivity Supplement.
Når data blir overført fra et miljø til et annet, kan det hende at de må konverteres. Denne konverteringen kan påvirke ytelsen.
Vurder disse plattformene:
og disse typene numeriske data:
Tabell 8 viser når det blir utført konvertering.
|
Intel |
IEEE |
S/370 og S/390 |
OS/400 |
---|---|---|---|---|
Pakkede desimaldata | ||||
Intel IEEE S/370/390 OS/400 |
Nei Nei Nei Nei |
Nei Nei Nei Nei |
Nei Nei Nei Nei |
Nei Nei Nei Nei |
Sonede desimaldata | ||||
Intel IEEE S/370/390 OS/400 |
Nei Nei Ja Ja |
Nei Nei Ja Ja |
Ja Ja Nei Nei |
Ja Ja Nei Nei |
Heltalldata | ||||
Intel IEEE S/370/390 OS/400 |
Nei Ja Ja Ja |
Ja Nei Nei Nei |
Ja Nei Nei Nei |
Ja Nei Nei Nei |
Flytetalldata | ||||
Intel IEEE S/370/390 OS/400 |
Nei Ja Ja Ja |
Ja Nei Ja Nei |
Ja Ja Nei Ja |
Ja Nei Ja Nei |
CPU-kostnaden ved konvertering av enkeltbytetegndata blir vanligvis mindre enn ved konvertering av numeriske data (når det er nødvendig med datakonvertering).
Kostnaden ved datakonvertering av DATE/TIME/TIMESTAMP er nesten den samme som ved enkeltbytetegn. Konvertering av flytetalldata koster mest. Applikasjonsutformeren kan ha nytte av disse faktaene når han/hun utvikler en applikasjon på grunnlag av DB2 Connect.
Hvis en databasetabell har en kolonne som er definert som 'FOR BIT DATA', er det ikke nødvendig å konvertere tegndataene som blir overført mellom applikasjonen og databasen. Dette kan du bruke når du arkiverer data på verts- eller AS/400-databasetjeneren.
Tegndata kan enten ha datatypen CHAR eller VARCHAR. Hvilken datatype som er mest effektiv, avhenger av den vanlige lengden på dataene i feltet:
Den beste måten å forbedre den generelle ytelsen på i et distribuert databasemiljø, er ved å unngå nettverksforsinkelser. Det er vanlig at nettverksansvarlige betrakter et nettverk som mer effektivt hvis det samler inn så mye data som mulig mellom overføringene. Denne løsningen fungerer ikke for distribuerte databaser fordi det skaper forsinkelser i nettverket. Sluttbrukeren ser ikke effektiviteten til nettverket, bare forsinkelsene.
De fleste nettverksenheter har forsinkelsesparametere, og de fleste av dem har standardverdier som fungerer svært dårlig for distribuerte databaser. For å forbedre ytelsen bør du finne disse parameterne og om mulig sette dem til null. I tillegg bør du sikre at bufferstørrelsen på enheten er stor nok til å forhindre nye overføringer av data som gikk tapt. UNIX-systemer har for eksempel vanligvis standardverdien 32 for sende- og mottakskølengden. Du få et bedre resultat hvis du setter kølengden til 150. Den tilsvarende parameteren i DLC-innstillingene er mottakslengden, som også bør være 150.
IOBUF-parameteren er satt for lavt de fleste steder. Den blir vanligvis satt til 500, men erfaring viser at verdien 3992 fungerer best hvis du flytter store mengder data, spesielt for kanaltilkoblinger som ESCON eller 3172.
For SNA-tilkoblinger bør du sette modusprofilen for alle typer arbeidsstasjonsprogramvare til 63. Generelt sett bør verdiene for mottakstakt i nettverket settes til maksimumsverdiene, og parameterne VPACING og PACING i DB2 APPL-setningen og PU/LU for arbeidsstasjonen i oppringt hovedmodus bør også settes til 63. På denne måten får du en progressiv økning av mengden meldinger som overføres, før senderen må vente på et svar.
På et lokalnettsystem kan størrelsene på sende- og mottaksvinduene for DLC eller LLC ha stor innvirkning på ytelsen. Sendeverdien bør settes til sju eller høyere, og for de fleste konfigurasjoner fungerer mottaksverdien fire eller lavere best.
Hvis du bruker Ethernet, bør du sette TCP-segmentstørrelsen til 1500 byte. På et token-ring- eller FDDI-nettverk bør denne verdien være 4400 byte, og hvis du bruker et ESCON-kort med TCP/IP, bør segmentstørrelsen alltid være 4096.
For TCP/IP-nettverk bør størrelsene på sende- og mottaksbufferne settes til en høyere verdi enn 32768. Verdien 65536 er vanligvis best.
Merk: | Det er mye dyrere å opprette en tilkobling fra portneren til tjeneren
(utgående tilkobling) enn å opprette en tilkobling fra en klient til portneren
(innkommende tilkobling). I et miljø der tusenvis av klienter ofte blir
koblet til og fra tjeneren gjennom portneren, går en stor del av
behandlingstiden med til å opprette utgående tilkoblinger. DB2 Connect
har støtte for tilkoblingsgrupper over TCP/IP. Når en klient ber om å
bli koblet fra tjeneren, avslutter portneren den innkommende tilkoblingen til
klienten, men den beholder den utgående tilkoblingen til tjeneren i en
gruppe. Når en ny klient ber portneren om en tilkobling, gir portneren
klienten en eksisterende tilkobling fra området, slik at den totale
tilkoblingstiden blir redusert, og slik at du slipper de høye
CPU-tilkoblingskostnadene på tjeneren.
Du finner flere opplysninger om tilkoblingsgrupper under DB2 i Administration Guide. |
Du finner et sammendrag over justeringsmetoder for nettverksytelse i
tabellen nedenfor.
Se etter | Eksempel | Innstilling | Merk |
---|---|---|---|
Tilsiktede forsinkelser | Forsinkelses- parametere på nettverksenheter | Sett til 0. | Standardverdiene er vanligvis høyere. |
Buffere | IOBUF-parameter | Sett til 3992. | Spesielt nyttig for ESCON eller et annet kanalkort. |
RUSIZE | Optimal størrelse er 4096. | Det kan gi best ytelse å definere samme størrelse for RUSIZE og RQRIOBLK. | |
Taktregulering | VPACING, PACING og modusprofiler bør settes til 63. | Bruk tilpasset taktregulering når det er mulig. | |
Innstillinger for kort | Lengde på sende-/mottakskø | Anbefalt verdi er 150. | Standardverdien er vanligvis 32. |
Størrelse på linjestyringsvindu (DLC) på SNA | Definer en høy verdi (>7) for størrelsen på sendevinduet. Definer en lav verdi (for eksempel 1) for størrelsen på mottaksvinduet, test og øk verdien gjentatte ganger for å finne den ideelle verdien. | Hver enkelt logisk enhet tilføyer forsinkelser. Bruk enkel nettverkstopologi så mye som mulig. | |
TCP-innstillinger | Segmentstørrelser | 1500 på Ethernet, 4400 på token-ring og FDDI. | ESCON-kort som blir brukt for TCP/IP, bør alltid settes til 4096. |
Størrelse på sende-/mottaksområde | Bør være 64 kB for begge. | Standardverdien er bare 8192 for Windows. Kan defineres i Windows-registeret. |
Du må ta følgende hensyn i forbindelse med maskinvaren:
Ytelsen blir forbedret med et raskt overføringsmedium. Dette er noen vanlige overføringshastigheter for datarader:
Dataoverføringshastigheten blir begrenset av det tregeste overføringsmediet i banen til verts- eller AS/400-databasetjeneren.
Du bør planlegge minnebruken for nettverkskortet og styreenheten for kommunikasjon nøye. I tillegg bør du samarbeide med en nettverksspesialist for å sikre at prosessoren har kapasitet til å håndtere den ekstra trafikken som DB2 Connect genererer.
Hvis det blir overført data fra et lokalnett til et annet, og fra et SNA-nettverk til et annet, må du vurdere reisetiden. Broer, rutefordelere og portnere øker også den medgåtte tiden. Hvis du for eksempel reduserer antallet broer som blir krysset, reduserer du antall hopp som er nødvendig for hver forespørsel.
Du bør også vurdere den fysiske avstanden mellom nodene. Selv om en melding blir overført med satellitt, blir overføringstiden begrenset av lysets hastighet (3 * 10**8 m/s) og rundturavstanden mellom senderen og mottakeren.
Hvis hele båndbredden for nettverket blir brukt, blir både svartiden og dataoverføringshastigheten for en enkelt applikasjon redusert.
Det kan oppstå overbelastning i nettverket hvis det samles opp data i en bestemt del av nettverket, for eksempel på en gammel NCP med en veldig liten bufferstørrelse.
Hvis det er en høy feilfrekvens i nettverket, reduseres hastigheten for nettverket, og dette kan føre til dårlig ytelse fordi data må sendes på nytt.
Ytelsen kan bli redusert hvis mange oppgaver på systemet kjemper om systemressursene. Vurder disse spørsmålene:
Hvis DB2 Connect-brukere opplever lang svartid under store spørringer fra verts- eller AS/400-tjenere, bør du undersøke følgende for å finne årsaken til ytelsesproblemet:
db2 update database manager configuration using RQRIOBLK 32767