⟦a61d13389⟧

TextFile

mode list.yes
vko2=set 50 disc3
afs6=set 50 disc3
scope user afs6
scope user vko2
vko11=set 200 disc3
afs6=typeset check.no hyphen.c.vko11 proof.vko2 machine.diablo
*se $* $pl ,30,235,,10$
$lw 160$$ld18$
$sb ^,6$
$pn 5,56$
$rh 1,VURDERING AF OP-SYSTEMET$
$ps0$
$ns 1,4,_«bs»6_«bs»._«bs»V_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».$
$np15$
Dette afsnit indeholder vurderingen af OP-systemet. Afsnittet er disponeret, så
afsnit 6.1 beskriver resultaterne opnået ved et elektronisk ur benyttet på
hele systemet. Ud fra dette begrundes, hvorfor den egentlige vurdering drejer
sig om RC8000-delen af OP-systemet. Afsnit 6.2 giver en vurdering af OP-systemet ud fra målinger i logfilen.
Afsnit 6.3 beskriver derefter, hvilke resultater der er opnået ved hjælp af den konstruerede
simulator. Afsnit 6.4 illustrerer de teoretiske modeller, der er betragtet.
Til samtlige kurver i dette afsnit findes i bilag 3 en tilsvarende tabel,
hvor resultaterne svarende til kurverne er angivet.
$ns 1,4,_«bs»6_«bs»._«bs»1_«bs»._«bs»A_«bs»f_«bs»g_«bs»r_«bs»æ_«bs»n_«bs»s_«bs»n_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»e_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»u_«bs»d_«bs»i_«bs»e_«bs»t_«bs».$
$np$
Ved vurdering af OP-systemet er foretaget en del begrænsninger. Disse begrænsninger
foretages således, at evalueringen kan koncentreres om centrale enheder i systemet.
Begrænsningerne er dels indført og begrundes ved,
at systemet indeholder mindre betydende enheder
og dels ved, at de eksisterende måleredskaber kun kan anvendes på dele af systemet.
$np$
Ved OP-systemet eksisterer et måleredskab til RC8000-delen (logfilen), der er velegnet
til fremskaffelse af oplysninger om systemets opførsel. Ved RC3500-delen eksisterer
denne mulighed ikke. Da det endog viste sig umuligt at konstruere et anvendbart
program til at finde en forespørgsels svartid i RC3500 (se afsnit 4.2),
er mulighederne for
målinger på OP-systemets RC3500-del begrænset til maskinelredskaber.
$np$
Ved hjælp af et elektronisk ur kan en forespørgsels samlede svartid findes.
Dette foregår ved, at uret ved hjælp af to sonder koblet til skærmens elektronik
registrerer tiden fra en forespørgsel afsendes til den modtages.
Ud fra
målingerne
med dette ur
kan beregnes, hvor meget tid de enkelte dele af OP-systemet anvender til
behandling af en forespørgsel.
$nl$
Nedenståedne tidslinie angiver, hvordan svartiden for en forespørgsel kan opdeles.
$sj$
Forespørgslen afsendes. Forespørgslen modtages.

!---!---!---!------------------------------!---!---!---!
TP NP FP RC8000 FP NP TP

Figur 6.1.1.
$rj$$nl$
De på figuren anførte forkortelser er betegnelser for de 3 RC3500, og betyder
følgende:
$sj$

TP = Terminal Processor
NP = Network Processor
FP = Front-end Processor
$rj$$np$
Målingerne med uret finder netop længden af denne tidslinie. I logfilen kan
svartiden i RC8000 findes. Ved at subtrahere disse størrelser beregnes,
hvor lang tid en forespørgsel benytter i de 3 RC3500 tilsammen.
$np$
I tabel 6.1.1 er den gennemsnitlige svartid i RC8000
for de 5 mest betydende forespørgselstyper angivet. Tallene stammer fra målinger i en logfil på et system
med samme maskinelkonfiguration som det, hvorpå målingerne er foretaget.
Udover den gennemsnitlige svartid for en forespørgselstype er antallet og
hyppigheden af forespørgselstyperne angivet.
$np$
De i tabellen anførte forespørgselstyper er udførligt beskrevet i afsnit 3.
Det kan her opsummerende anføres, at en søgeforespørgsel afvises enten på
grund af, at stednavnet ikke findes, eller hvis antallet af kandidater
er større end 63 eller mindre end 1.
$ps$
$sj$

Antalforsp. Hyppighed i % Gnst. svartid
i RC8000

Gennemført søgeforsp. 19625 35.6 % 884 ms
Afvist søgeforsp. 15155 27.5 % 589 ms
Bladn.+Hemmnr.+Fejl 7247 13.1 % 57 ms
Gennemført tlfnrforsp. 12228 22.2 % 183 ms
Afvist tlfnrforsp. 873 1.6 % 141 ms
____________________________________________________________

Ialt 55128 100.0 % 526 ms
=============================================================

Tabel 6.1.1.
$rj$$np$
I tabellen er den gennemsnitlige svartid, angivet i linien ialt vægtet efter
hyppighed af forespørgselstype.
$np$
Tabellen viser, at de hyppigst forekommende forespørgslestyper er søgeforespørgsler,
og netop disse forespørgsler har den største svartid i RC8000. En dyberegående fortolkning
af, hvad tabellen viser gives først i afsnit 6.2. Dette skyldes,
at tabellen her primært anvendes til at finde den gennemsnitlige svartid
for en forespørgsel i RC3500.
$np$
For hver af de i tabellen anførte forespørgselstyper er foretaget 5
observationer med et elektronisk ur. Hver
observation bygger på, at en udvalgt forespørgsel er afsendt 50 gange og
hver gang er svartiden noteret. Valget af de afsendte forespørgselstyper er foretaget således,
at antallet af kriterier og kriteriesammensætningen svarer til de hyppigst benyttede.
$np$
Tabel 6.1.2 viser resultaterne, hvor den gennemsnitlige svartid for de 5 observationer til hver forespørgselstype er fundet.
Ligeledes her er den gennemsnitlige svartid ved linien ialt vægtet efter hyppighed
af forespørgselstypen. For hver linie i tabellen er angivet den procentvise fordeling
af svartiden i RC8000 og i RC3500.
$ps$
$sj$
Samlet svartid Svartid i RC8000 Svartid i RC3500

Gennemført søgeforsp. 1027.4 ms 884 ms 143.4 ms
Procentlig fordeling 100 % 86.0 % 14.0 %

Afvist søgeforsp. 857.2 ms 589 ms 268.2 ms
Procentlig fordeling 100 % 68.7 % 32.3 %

Blad.+Hemmnr.+Fejl. 455.6 ms 57 ms 398.6 ms
Procentlig fordeling 100 % 12.5 % 87.5 %

Gennemført tlfnrforsp. 521.9 ms 183 ms 338.8 ms
Procentlig fordeling 100 % 35.0 % 65.0 %

Afvist tlfnrforsp. 435.5 ms 141 ms 291.5 ms
Procentlig fordeling 100 % 32.4 % 67.6 %
_______________________________________________________________

Ialt 783.8 ms 526 ms 256.9 ms
Procentlig fordeling 100 % 67.0 % 33.0 %
===============================================================

Tabel 6.1.2.
$rj$$np$
Tabel 6.1.2 viser, at for gennemførte og afviste søgeforespørgsler (de hyppigste)
anvendes mest tid i RC8000. For afviste-, gennemførte tlfnr.forespørgsler og
bladningsforespørgsler er forholdet det modsatte, idet til behandling
af disse bruger RC3500 mest tid. Det fremgår endda, at RC3500 bruger
mere tid til de 3 sidstnævnte forespørgselstyper end for de to førstnævnte.
Ved en bladningsforespørgsel kan dette begrundes med følgende:
$np$
De bladningsforespørgsler, som de 5 observationer til denne forespørgselstype
bygger på, havde 3 sider med kandidater. Ved hver bladning skulle et helt
skærmbillede således sendes gennem de 3 RC3500. Dvs. der
ved denne forespørgselstype skulle sendes mere data gennem en RC3500 end ved f.eks.
en søgeforespørgsel. Det forekommer rimeligt, at behandlingstiden i en
RC3500 bl.a. afhænger af mængden af data, der transporteres, og derfor
vil behandlingstiden i RC3500 ved en bladning være større end ved en søgeforespørgsel.
Da det er meget tidskrævende og vanskeligt
at undersøge, hvorfor de forskellige forespørgselstyper
ikke har lige lange
behandlingstider i RC3500, og mere præcist at angive, hvor meget tid de
enkelte forespørgselstyper benytter i RC3500,
er dette ikke undersøgt nærmere.
Begrundelsen for dette uddybes i nedenstående.
$np$
Udover at de hyppigst anvendte forespørgselstypers svartid er størst i RC8000,
kan i tabel 6.1.2 ses, at den gennemsnitlige svartid for samtlige
forespørgselstyper er over dobbelt så stor i RC8000 som i RC3500.
På denne baggrund bør en evaluering af OP-systemet kunne koncentreres om en RC8000.
$np$
Under evalueringen af en RC8000 har det vist sig, at ovenstående tabel endda er ret
unøjagtig.
Målingerne ved det elektroniske ur er foretaget en hverdag mellem 9.30-14.30.
Dette er det tidspunkt på dagen, hvor OP-systemet er mest belastet. Fra
senere undersøgelser se figur 6.2.1( side 65) kan anføres, at antallet af forespørgsler pr. time
i det anførte tidsrum er mindst 10.000.
$np$
Målingerne er udført i efteråret 1980,
hvor der til OP-systemet anvendtes 2 RC8000. Det vil sige, der er mindst
5000 forespørgsler pr. time til en RC8000. Ved dette antal vil den gennemsnitlige
svartid for en forespørgsel i RC8000
ikke være 526 ms, men mindst 650 ms (se figur 6.2.5 side 74).
De 650 ms er fundet ved hjælp af en KTASSTAT. Dette program anvendes, som beskrevet
i afsnit 5.2, bl.a. til at finde, hvordan den gennemsnitlige svartid
for samtlige forespørgselstyper afhænger af antal forespørgsler pr. time.
Ved hjælp af dette program er det ikke muligt at finde de enkelte
forespørgselstyper svartids afhængighed af belastningen. Dette
skyldes den belastningsmodel som jeg betragter se afsnit 4.

$np$
Tabel 6.1.3 viser, hvordan svartiden fordeler sig i RC8000 og RC3500
med den mere nøjagtige svartid fundet fra en KTASSTAT svarende
til en belastning på mindst 5000 forespørgsler pr. time.
$ps$
$sj$
Samlet svartid Svartid i RC8000 Svartid i RC3500
For samtlige forsptyper 783.8 ms 650 ms 133.8 ms
Procentlig fordeling 100 % 82.9 % 17.1 %

Tabel 6.1.3
$rj$$nl$
Denne tabel viser tydeligere end tabel 6.1.2, at den meste tid
af svartiden for en forespørgsel går i RC8000.
$np$
Med de i tabellen anførte svartider i RC8000 og RC3500
betragtes nu hele OP-systemet som vist på figur 6.1.2. Forkortelserne anført på
figuren står for det samme som angivet ved figur 6.1.1.
$fg 100$

$np$
Systemet betragtes i en hårdt belastet time for at finde udnyttelsesgraden af de indgående enheder.
Da de 3 RC3500 tilsammen benytter 133.8 ms, antages det, at hver benytter 44.6 ms. Fra
en KTASSTAT den 24.04.81 kan CPU-udnyttelsen af de 3 RC8000 i den hårdest belastede
time (mellem 10-11) findes til 66.9%.
CPU-udnyttelsen er fundet ved at summere CPU-udnyttelsen af de 4 processer.

Hvis det antages, at forespørgslerne
fordeles ligeligt mellem de 3 RC8000 så findes, at udnyttelsesgraden af hver til 22.3 %. Udnyttelses af de RC3500 betegnet FP og NP beregnes til
$sj$

13107 * 44.6
____________ * 1/2 * 100 = 8.1 %
60*60*1000
$rj$
$np$
Her er 13107 antal forespørgsler i den betragtede time, og 44.6 ms er
behandlingstiden i en RC3500.
Der multipliceres med 1/2, idet der findes 2 af hver. For RC3500 betegnet
TP findes udnyttelsesgraden til 1.1 %, idet der mindst findes 15 af denne type.
$np$
Begrundelsen for kun at betragte OP-systemets RC8000-del ved resten af evalueringen, kan nu på baggrund af ovenstående opsummeres i
følgende punkter:
$lm20$$nl$
$lt 1,^^^1)$
En RC8000 er den enhed der har højst udnyttelsesgrad (3 gange så stor som
nogen anden enhed).
$nl$
$lt 1,^^^2)$
RC8000 benytter mest tid til at behandle en forespørgsel.
$nl$$lt 1,^^^3)$
I RC8000 findes i modsætning til RC3500 et udmærket måleredskab (logfilen) til
en evaluering.
$lm0$
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»V_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t__«bs»u_«bs»d__«bs»f_«bs»r_«bs»a__«bs»m_«bs»å_«bs»l_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»i__«bs»l_«bs»o_«bs»g_«bs»f_«bs»i_«bs»l_«bs»e_«bs»n_«bs».$
$np$
Dette afsnit indeholder vurderingen af en RC8000 koblet til OP-systemet.
Vurderingen bygger på målinger foretaget i logfilen.
Afsnittet indledes med et beskrive, hvilke målinger der er foretaget. Derefter angives,
hvilken belastning en RC8000 udsættes for. Så følger en analyse af de betragtede præstationsindices afhængighed af belastningen. Herefter undersøges, hvordan
de indgående programmel- og maskinelenheder udnyttes. Til sidst gives
en samlet vurdering af OP-systemet RC8000-del,
i en hårdt belastet time.
$np$
Ud fra vurderingen i dette afsnit vil det fremgå,
hvilke dele af systemet, der bevirker en formindskelse i dets ydeevne.
På baggrund af disse betragtninger, vil en række forbedringsforslag til OP-systemet kunne opstilles. Disse forbedringsforslag
vil blive afprøvet ved hjælp af en simulator, og det beskrives i afsnit 6.3,
hvad der herved opnås.
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»1_«bs»._«bs»D_«bs»e__«bs»f_«bs»o_«bs»r_«bs»e_«bs»t_«bs»a_«bs»g_«bs»n_«bs»e__«bs»m_«bs»å_«bs»l_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r_«bs».$
$np$
Målingerne i logfilen er foretaget ved hjælp af to programmer OPSTAT
og KTASSTAT, der findes beskrevet i afsnit 5.
Ved kørsler med programmet KTASSTAT
har der været en del problemer som skyldes følgende:
$np$
Logfilen til RC8000 kan indeholde information for enten 3 eller en maskine. Når logfilen
gennemløbes, er det ikke muligt at se, på hvilken måde logfilen er dannet.
Normalt indeholder logfilen
transaktioner fra 3 maskiner. En sådan
logfil kan kun anvendes meget lidt ved denne vurdering. Dette
skyldes, at evalueringen bl.a. skal undersøge, hvordan RC8000 opfører sig, når
belastningen øges.
Da transaktionerne ikke fordeles ligeligt
mellem de 3 RC8000 vil belastningen for hver maskine således være forskellig.
Når en RC8000 undersøges, benyttes derfor kun oplysninger dannet fra transaktionerne
på en maskine.
$np$
Begrundelsen, for hvorfor fordelingen af transaktioner ikke sker, således at hver
RC8000 modtager lige mange forespørgsler, er angivet i afsnit 3.
$np$
Den efterfølgende vurdering bygger på 6 kørsler med KTASSTAT foretaget på en logfil med een maskines transaktioner, 1 kørsel med KTASSTAT og en OPSTAT på en logfil
med 3 maskiners transaktioner. De 6 første kørsler er fra mandag den 23.03.81-fredag den 27.03.81 og mandag den 30.03.81. De 2 sidste kørsler er fra fredag den 24.04.81.
$np$
Kørslerne fra logfilen med 3 maskiners transaktioner benyttes til at beskrive
hvor mange forespørgsler, der modtages i hver time i døgnet,
og til at finde,
hvordan svartiden for de forskellige forespørgselstyper er.
$np$
De 6 kørsler anvendes til at beskrive en RC8000's afhængighed af belastningen.
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»2_«bs»._«bs»B_«bs»e_«bs»l_«bs»a_«bs»s_«bs»t_«bs»n_«bs»i_«bs»n_«bs»g_«bs»e_«bs»n__«bs»a_«bs»f__«bs»e_«bs»n__«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0__«bs»t_«bs»i_«bs»l__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».$
$np$
I afsnit 4.2 er beskrevet, hvordan belastningen til en RC8000 betragtes. Opsummerende
kan her anføres, at belastningen består af et antal forespørgsler og disse
forespørgslers karakteristika. Forespørgslernes karakteristika beskrives
dels ved deres vej gennem systemet og dels ved deres CPU-forbrug. En forespørgsels
vej gennem systemet er en måde at angive forespørgselstypen.
$np$
Nedenstående analyse af belastningen opdeles på ækvivalent måde, dvs. først
betragtes, hvor mange forespørgsler systemet modtager i løbet af døgnet, og derefter
beskrives forespørgslernes art og tidsforbrug.
$np$
Figur 6.2.1 viser et histogram over forespørgslernes antal fordelt på et døgn.
Ud af X-aksen er angivet klokkeslet i døgnet, og Y-aksen angiver antallet af forespørgsler.
Eksempelvis kan ses, at mellem kl. 10.00-11.00 er ankommet 13107 forespørgsler.
Figuren bygger på KTASSTAT fra den 24.04.81.
$np$
Figuren viser, at aktiviteterne til OP-systemet i nattetimerne (23.00-7.00)
er særdeles begrænset.
Her ankommer aldrig mere end 500 forespørgsler i timen.
Aktiviteterne i dag- og aftentimerne er derimod mere hyppig. Kurven viser, at
den hårdest belastede time er mellem kl.10.00-11.00, hvor
der til OP-systemet sendes 13107 forespørgsler.
Dette svarer til, at hver tasteoperatør
i gennemsnit afsender en forespørgsel for hver 35 sekund. Når en person ringer
til telefonnummeroplysningen giver dette i gennemsnit anledning til 2.5 forespørgsler. Dvs. telefonnummeroplysningen i den mest belastede time behandler 4369
spørgsmål.
$ps$$ps$
$np$
Kurven figur 6.2.1 viser endvidere at belastningen af systemet er størst i
tidsrummet mellem 9-16. I denne periode sker et lille fald i aktiviteterne
omkring frokost (12-13).
$np$
OP-systemets RC8000-dels reaktionsevne på dette antal
forespørgsler afhænger nu udover transaktionernes antal af forespørgslers art.
Til betragtning af deres art beregnes en overgangssandsynlighedsmatrix se afsnit 5.2.1. Matricen, som er fundet ud fra samtlige
forespørgsler (129185) den.24.04.81. har følgende udseende:
$sj$
input søge opslags output

input 0 0.66 0.21 0.13
søge 0 0 0.58 0.42
opslags 0 0 0 1

output 0 0 0 0
$rj$$np$
Matricen skal nu opfattes på følgende måde: Rækkeindeks angiver fra hvilken proces
forespørgslen afsendes, og søjleindekset beskriver, hvilken proces forespørgslen
modtages af.
$np$
Dvs. der har været 66 % søgeforespørgsler, hvoraf 58 % er gennemførte og
42 % afviste. Matricens afhængighed af antallet af forespørgsler pr. time,
kan findes. Det viser sig, at matricen er særdeles konstant, hvilket egentlig
også kunne forventes. Spredningen for tallene i matricen er meget lille. Hvis
matricen beregnes for hver time i døgnet, findes spredningen på de indgående tal til følgende:
$sj$

input -> søge = 0.04
input ->opslags = 0.04
input ->output = 0.04
søge ->opslags = 0.03
søge ->output = 0.03
$rj$
$np$
At den maksimale spedning er 0.04 skyldes, at matricen for timer med mindre end
1000 forerspørgsler variere en del. Hvis spredningen beregnes svarende til timer,
hvor antallet af forespørgsler pr. time
er mere end 1000, så findes den maksimale spredning
til 0.016. Her bygger spredningen på 99.1 % af døgnets forespørgsler. Timerne
hvor antallet af forespørgsler er mindre end 1000 udgør således en meget lille
del af samtlige forespørgsler.
$np$
Konkluderende kan derfor siges, at forespørgselsmønsteret ikke afhænger af tidspunktet på dagen, og det er særdeles konstant.
$np$
Udover forespørgslernes art er den sidste faktor, der har indflydelse på belastningen
af en RC8000,
forespørgslernes ressourcekrav. Nedenstående vil først belyse deres CPU-tidskrav i de enkelte processer.
Derefter betragtes en forespørgsels samlede CPU-forbrugs afhængighed af antal forespørgsler pr. time.
$np$
Det gennemsnitlige CPU-tidskrav for en forespørgsel kan findes direkte fra logfilen.
For de fire processer er den gennemsnitlige CPU-tid (angivet i ms) følgende:
$sj$

CPU-tid i inputproces = 16.3 spredning = 5.51
CPU-tid i søgeproces =179.74 spredning = 300.46
CPU-tid i opslagsproces= 68.08 spredning = 103.38
CPU-tid i outputproces = 9.05 spredning = 6.23
$rj$$nl$
Det ses, at søgeprocessen benytter mest CPU-tid. CPU-tiden i input- og
outputprocessen udgør en lille procentdel af den samlede svartid ( hhv. 2.8 og
1.6 %).
$np$
Da der er særdeles stor spredning på CPU-tiden betragtes nøjere, hvordan CPU-tiden fordeler sig.
Figur 6.2.2 viser, hvordan fordelingen af CPU-tiden er i input-
og outputprocessen.
$np$
Fordelingen er fundet ved at optælle antallet af forespørgsler, hvis
CPU-tid er i et interval eks. 10-11 ms. På figuren angives ud af
X-aksen CPU-tiden og ud af Y-aksen anføres sandsynligheden i % for at
forespørgslens CPU-tid befinder sig i intervallet. Kurven viser
således tæthedsfunktionen for CPU-tiden.
$ps0$$ps0$$ps0$
$np$
Kurven for inputprocessen viser, at de fleste forespørgsler har et
ret konstant CPU-forbrug. Således har 84.9 % af samtlige forespørgsler
en CPU-tid mellem 12 og 19 ms. Dette kendetegnes også ved, at
CPU-tiden i inputprocessen har en lille spredning.
$np$
Kurven for CPU-tiden i outputprocessen viser næsten samme billede. Her har
79.1 % af samtlige forespørgsler en CPU-tid mellem 5-10 ms. Det
bemærkes, at punktet i cirklen på kurven for outputprocessen stammer fra forespørgsler, hvis CPU-tid er større end 14 ms.
Dette punkt er således misvisende og kurvens forløb vil ikke stige til dette
punkt.
$np$
For søge- og opslagsprocesserne findes kurverne på figur 6.2.3. Kurven for
CPU-tiden i søgeprocessen ligger tæt på eksponentialfordelingen med samme
middelværdi(179.74). Denne er på figuren angivet som en stiplet linie.
Ud fra kurven kan ses, at 70.7 % af samtlige forespørgsler har en CPU-tid mindre end 180 ms. Det mest iøjnefaldende for kurven er, at den har et faldende
forløb, og ikke afspejler at søgeprocessen behandler forskellige forespørgselstyper.
$np$
Kurven svarende til CPU-tiden for opslagsprocessen viser ligeledes, at den ligger tæt
op ad eksponentialfordelingen med samme middelværdi.
Dette kan undre en del, da opslagsprocessen
både behandler gennemførte søgeforespørgsler og tlfnr.forspørgsler. Disse to
forespørgselstyper adskiller sig ved, at tlfnr.forspørgsler højst har en kandidat og
gennemførte søgeforespørgsler i gennemsnit har 7.5 kandidater. Man kunne
derfor forvente, at kurven for CPU-tiden ville have
to toppunkter svarende til de to forespørgselstyper.
$np$
En samlet vurdering af CPU-forbruget er, at fordelingen af CPU-tiden i de enkelte
processer ikke viser, at de forskellige forespørgselstyper adskiller sig
ved differencerede CPU-forbrug.
$ps0$
$ps0$
Figur 6.2.4 viser en kurve over det gennemsnitlige CPU-forbrug for en forespørgsel. Ud af X-aksen er angivet antallet af forespørgsler pr. time, og Y-aksen
angiver den samlede CPU-tid for en forespørgsel. (summen af CPU-tiden i de 4 processer.)
Punkterne til kurven er fremkommet ved at samle antallet af timer, hvor antallet af
forespørgsler er mellem 0-500, 500-1000 ovs. Ud fra disse timer findes
først det gennemsnitlige antal forespørgsler og derefter findes den gennemsnitlige CPU-tid.
Dette er gjort for at få et overskueligt antal punkter.
$np$
Figuren er tegnet på grundlag af KTASSTAT fra den 23.03 og 24.03.
Grunden til at kurven ikke er tegnet for hver proces er, at de viser samme billede som på figuren. Punktet svarende til et gennemsnit på 70.3 forespørgsler pr time
er noget misvisende, idet variansen på målingerne her er særdeles stor. De
ligger i intervallet 176.0 - 588.2 ms.
$np$
Figuren viser, at der er særdeles stor varians i CPU-tiden. Derudover ses,
at CPU-tiden ikke afhænger af antallet af forespørgsler.
Udover en forespørgsels CPU-tid hører til deres ressourcekrav også, hvor mange
pladelagertilgange de anvender. Denne størrelse er ikke målelig i logfilen.
I afsnit 3 er angivet en metode, hvorved antallet af pladelagertilgange
i de enkelte processer kan
findes. For søgeprocessen er dette fundet til 13.9 pr. forespørgsel og for opslagsprocessen er
det 5.5 pr. forespørgsel.
Det er ikke muligt at angive, hvor stor spredning der er på disse
tal.
$np$
Konkluderende om belastningen kan nu på baggrund af ovenstående anføres
følgende. Forespørgslernes art
er uafhængig af, hvor mange forespørgsler, der modtages. Input- og outputprocessen er
de processer, der benytter mindst CPU-tid.
Søgeprocessen benytter mest CPU-tid. Den procentvise fordeling af CPU-tiden er input = 6 %, søge = 65.8 %, opslag = 24.9 % og output = 3.3 %. Når belastningen af systemet betragtes i det følgende,
vil den blive kvantificeret som antallet af forespørgsler ankommende i en time.
Dette gøres, da det er eneste størrelse i belastningen, der ændres.
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»3_«bs»._«bs»P_«bs»r_«bs»æ_«bs»s_«bs»t_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»i_«bs»n_«bs»d_«bs»i_«bs»c_«bs»e_«bs»s__«bs»a_«bs»f_«bs»h_«bs»æ_«bs»n_«bs»g_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d__«bs»a_«bs»f__«bs»b_«bs»e_«bs»l_«bs»a_«bs»s_«bs»t_«bs»n_«bs»i_«bs»n_«bs»g_«bs»e_«bs»n_«bs».$
$np$
Først betragtes den gennemsnitlige svartids afhængighed af belastningen.
Derefter bliver den gennemsnitlige svartid opdelt, således at tidsforbruget
i de enkelte processer anskueliggøres.
$np$
Figur 6.2.5 viser, hvordan svartiden afhænger af antallet af forespørgsler.
Kurven er konstrueret på grundlag af samtlige kørsler med KTASSTAT på een maskine.
For ikke at få et uoverskueligt antal punkter er observationerne samlet således
at alle timer med et antal forespørgsler på mellem 0-249,250-499,ovs er samlet til et punkt.
Svarende til punktet med mellem 0 og 249 forespørgsler pr. time er der særdeles
stor varians, så den gennemsnitlige svartid er her noget misvisende.
$np$
Kurven viser, at den gennemsnitlige svartid stiger i forhold til antallet af
forespørgsler. Ved lave belastninger er variansen på svartiden stor.
Dette kommer ikke fra at forespørgselstyperne er forskellige ved denne belastning, men må komme fra at antallet af kandidater til forespørgslerne varierer meget.
For yderligere at anskueliggøre, at den gennemsnitlige svartid stiger i timer, hvor
antallet af forespørgsler er stort, er på figur 6.2.6 angivet, hvordan
svartiden fordeler sig ved to timer. Den ene time svarer til at der er modtaget
1210 forespørgsler. Ved denne belastning besvares 95 % af forespørgslerne
under 1250 ms. Den anden kurve svarer til en belastning på 5733 forespørgsler
pr. time. Her besvares kun 82 % af forespørgslerne under 1250 ms.
$np$
Ved en belastning på over 5000 forespørgsler i en time vil 55 % af forespørgsler besvares indenfor 500 ms. Ved en belastning på under 1500 forespørgsler
besvares 75 % af forespørgslerne under 500 ms. Det er således klart, at
svartiden stiger, når antallet af forespørgsler pr. time forøges. Dette
er naturligvis også, hvad der kunne forventes, og det interesante er,
hvilke størrelser i svartiden, der stiger kraftigst, når belastningen til
systemet øges.
$ps$$ps$$ps$
Fra afsnittet om belastningen vides, at CPU-tiden ikke forøges væsentligt.
Der er således to andre størrelser, som bør betragtes. Dette er procestiden,
dvs. den tid en forespørgsel befinder sig under behandling i en proces, og
køtiden, den tid en forespørgsel opholder sig i kø til en proces.
$np$
Kurven figur 6.2.7 viser, hvordan procestiden i input- og outputprocessen
forløber, når antallet af forespørgsler forøges. På figuren er ud af X-aksen
angivet antallet af forespørgsler pr. time og Y-aksen angiver procestiden i ms.
$np$
For begge processer viser kurven et stigende forløb. At procestiden stiger,
når antallet af forespørgsler stiger, virker ret rimeligt. Når der er
ringe belastning til systemet vil en proces kunne behandle en forespørgsel,
uden at andre processer har nogle forespørgsler at behandle.
$np$
For både input- og outputprocessen gælder, at procestiden forøges,
når belastningen øges, men
deres indflydelse på den samlede svartid er stadig ringe. Det bemærkes, at
der ikke til inputprocessen er koblet et pladelager så forøgelsen af procestiden
stammer her kun fra at systemet er multiprogrammeret.
$np$
Da procestiden i input- og outputprocestiden har særdeles ringe indflydelse på
den samlede svartid, er det mere interessant at betragte procestiden i søge- og
opslagsprocessen. Figur 6.2.8 viser procestidens afhængighed af belastningen
i hhv. søge- og
opslagsprocessen.
$np$
For søgeprocessen viser kurven ikke nogen udpræget stigning i forhold til antallet
af forespørgsler pr. time,
når først antallet af forespørgsler er over 2000.
For opslagsprocessen viser
kurven en noget mere udpræget stigende tendens.
$np$
Hele tendensen fra disse kurver på figur 6.2.7 og 6.2.8 er,
at processer der benytter lidt CPU-tid,
input- output- og delvist opslagsproces,
viser en stigende tendens for procestiden
når antallet af forespørgsler pr. time forøges. For søgeprocessen har multiprogrammeringsgraden
ikke samme indflydelse på procestiden. Konklusionen af disse kurver
er, at forøgelsen i svartiden i forhold til belastningen ikke
kan forklares ved, at procestiden forøges.
$ps$$ps$$ps$
$np$
Figur 6.2.9 og figur 6.2.10 viser, hvordan køtiden ved hhv. søge- og opslagsprocessen afhænger af
belastningen. Kurven for køtiden ved søgeprocessen viser klart en stigende tendens. Køtiden bliver ved denne proces en betydende faktor i den gennemnsitlige svartid.
Ved en belastning på 6305 forespørgsler udgør køtiden 44.6 % af svartiden ved søgeprocessen.
Køtiden ved opslagsprocessen stiger ligeledes, men tidmæssigt har denne størrelse
ikke så stor indflydelse på svartiden.
$np$
De indtil nu anførte præstationsindices afhængighed af
belastningen har vist, at ved køtiden for søge- og opslagsprocessen
sker den største stigning. For de andre indices er stigningen ikke så kraftig. Størrelsesmæssigt
får køtiden ved søgeprocessen den største indflydelse på den gennemsnitlige svartid.
Dette betyder så, at når antallet af forespørgsler pr. time
stiger, vil der ske en kraftig stigning i svartiden for søgeforespørgsler.
For tlfnr.forespørgsler vil der også ske en stigning, men
den vil ikke tidsmæssigt være så stor.
$np$
Hvis to timer med hhv. ca. 100 og ca. 4000 forespørgsler betragtes, vil der i procestiden
i søgeprocessen ske en stigning på ca. 90 ms. Ved opslagsprocessen vil procestiden
kun stige ca. 35 ms. For køtiden sker ved søgeprocessen
en stigning på ca. 350 ms mod ca. 60 ms ved opslagsprocessen.
$np$
Konklusionen af dette afsnit om præstationsindices afhængighed af antal
forespørgsler pr. time er derfor, at søgeprocessen er den proces, der dårligst
klarer en stigning i belastningen. Dette vil endnu klarere blive vist under vurderingen ud fra simulatoren.
$ps$$ps$$ps$
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»3_«bs»._«bs»V_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»e_«bs»n__«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0__«bs»i__«bs»e_«bs»n__«bs»h_«bs»å_«bs»r_«bs»d_«bs»t__«bs»b_«bs»e_«bs»l_«bs»a_«bs»s_«bs»t_«bs»e_«bs»t__«bs»t_«bs»i_«bs»m_«bs»e_«bs».$
$np$

En hårdt belastet
time, hvor antallet af forespørgsler er 5733 betragtes nu.
Her findes CPU-udnyttelsesgraden af
de 4 processer følgende:
$sj$
inputproces = 2.6 %
søgeproces = 19.0 %
opslagsproces = 6.8 %
outputproces = 1.5 %
$rj$$np$
For at kunne beregne den totale udnyttelse af CPU-en er, det nødvendigt at
finde, hvor meget monitoren benyttes. Det vides ikke, hvor lang
tid monitoren er om at skifte mellem 2 processer.
Ved at betragte timer, hvor belastningen er ringe, dvs. der kommer under 1000
forespørgsler i en time, er det muligt at angive, hvor lang tid
en forespørgsel er om at skifte mellem to processer. Dette kan ses på køtiden.
Ved en lille belastning skulle forventes, at køtiden er 0, men her må køtiden
kunne opfattes som den tid en forespørgsel er om at skifte mellem to processer.
Der er særdeles stor varians i køtiden i timer med ringe belastning.
Ved en meget lille belastning kan det forekomme, at to forespørgsler skal behandles
samtidigt. Dette bevirker, at enkelte af disse timer har misvisende store køtider.
Hvis køtiden beregnes som gennemsnittet for alle observerede timer med
mindre end 100 forespørgsler bliver køtiden derfor for stor. Nedenstående angiver, hvor stor
køtiden er ved de 3 processer i en ringe belastet time, dvs. når de misvisende timer
ikke medtages.
Der opnås da følgende:
$sj$

køtid ved søgeproces = ca. 4.2 ms
køtid ved opslagsproces= ca. 4.2 ms
køtid ved outputproces = ca. 7.0 ms
$rj$$np$
Ved at beregne ud fra antallet af forespørgsler ved hver proces, hvor tit
en forespørgsel skifter mellem de enkelte processer fås da, at udnyttelsen
af monitoren ved en belastning på 5733 er 1.8 %. Den samlede CPU-udnyttelse
findes derved til 31.7 %.
CPU-udnyttelsen er fundet som summen af CPU-udnyttelses af de 4 processer
og monitorudnyttelsen.
Dette må siges at være særdeles lille i betragtning
af at den gennemsnitlige svartid ved denne belastning er 686.8 ms. Ved en
gennemsnitlig belastning på 2000 forespørgsler pr. time er den gennemsnitlige svartid ca. 430 ms.
$np$
Fordelingen af svartiden ved belastningen på 5733 forespørgsler pr. time
er vist som den stiplede linie figur 6.2.6. Det kan til denne figur tilføjes,
at
95 % af forespørgslerne besvares under 2500 ms. Den mindste svartid er 11 ms, og den
største er 9666 ms.
$np$
I betragtning af, at CPU-en kun udnyttes i 31.7 %
er der ved denne belastning således sket en pæn stigning i den gennemsnitlige svartid i forhold til timer med mindre belastninger.
Det vil
derfor være interessant at betragte, hvor stor udnyttelsesgraden er
af de andre enheder.
$np$
Ud fra afsnit 3, hvor antallet af pladelagertilgange i de
enkelte processer er angivet kan udnyttelsen af de 3 diske og
datakanalen findes.
$nl$$sj$
Søgediskudnyttelse
=
antal disktilgange * antal forsp. i søge * disktilgangstid
____________________________________________________________
60 * 60 * 100
13.9 * 3687 * 16.3
=___________________ *100= 23.2 %
60 * 60 * 100
Opslagsdiskudnyttelse

5.5 * 3511 * 16.3
= ____________________ * 100 = 8.7 %
60 * 60 * 100

outputdiskudnyttelse

0.07 * 5733 * 16.3
= ___________________ * 100 = 1.8 %
60 * 60 * 100

Diskkanaludnyttelse

(13.9 * 3687 + 5.5 * 3511 + 0.07 * 5733) * 8.3
=_______________________________________________ * 100 =16.4 %
60 * 60 * 100
$rj$$np$
Antal disktilgange i outputprocessen er sat til 0.07 pr. forespørgsel. Dette
stammer fra, at med dette tal gav simulatoren de bedste resultater.
$np$
Det ses, at den enhed, der er udnyttet mest ved en RC8000 til OP-systemet er
centralenheden. Svarende til, at de beregnede tal er for den hårdest
belastede time, og der er sket en kraftig stigning i
svartiden, er det bemærkelsesmæssigt, at ingen enhed er udnyttet mere end
31.7 %. Ud fra disse betragtninger vil det være interessant at
betragte systemets opførsel ved endnu større belastninger. Dette vil
blive gjort i nedenstående afsnit.

$ns 1,4,_«bs»6_«bs»._«bs»3_«bs»._«bs»V_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t__«bs»v_«bs»e_«bs»d__«bs»h_«bs»j_«bs»æ_«bs»l_«bs»p__«bs»a_«bs»f__«bs»e_«bs»n__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs».$
$np$
Dette afsnit beskriver de resultater der er opnået i forbindelse
med kørsel med den udviklede simulator. Simulatoren er beskrevet
simulatoropgaven.
Det kan her opsumeres, at det er lykkedes at gøre simulatoren ret
nøjagtig. Således er der ved en belastning på 2000 forespørgler en
afvigelse på den gennemsnitlige svartid på 0.1 %. Ved 6000 forespørgsler
er afvigelsen på den gennemsnitlige svartid på 4.9 %. En kurve
for svartidens udvikling når belastningen øges, har det derudover vist,
at simulatorens resultater for den gennemsnitlige svartid ligger tæt
op ad resultaterne, der er opnået ved målinger i logfilen.
$np$
Ud fra målinger i logfilen har det vist sig, at den
største udnyttelsesgrad af en RC8000, er 31.7 %. Dette svarer til en belastning
på 5733 forespørgsler. Svarende til denne belastning findes en gennemsnitlig svartid på 686.8 ms.
I betragtning af den lave udnyttelsesgrad af RC8000 er denne svartid ret stor.
Specielt i forhold til at den gennemsnitlige svartid over et helt døgn er
574.5 ms.(Den 24.04.81) Ved hjælp af simulatoren vil det blive undersøgt, hvad
baggrunden er for at CPU-en ikke udnyttes bedre. Der er således foretaget en serie kørsler med simulatoren for at afklare, hvordan den gennemsnitlige svartid
afhænger af antallet af forespørgsler pr time. Ved disse kørsler er en RC8000
udsat for væsentlig større belastninger end den vil være ved OP-systemet.
$np$
Svarende til at CPU-tidskravet og antallet af pladelagertilgange er det samme
som ved OP-systemet viser figur 6.3.1, hvordan den gennemsnitlige svartid forøges,
når antallet af forespørgsler pr. time forøges. På figuren er antallet af forespørgsler angivet ud af X-aksen, og den gennemsnitlige svartid er anført op ad Y-aksen.
Kurven viser, at den gennemsnitlige svartid stiger særdeles kraftigt,
når antallet af forespørgsler pr time er over 8000. Således er den gennemsnitlige
svartid svarende til 8000 forespørgsler = 868.9 ms. Når belastningen øges til
10.000 forespørgsler er svartiden 1528.7 ms. Fra dette punkt sker nærmest en eksposiv stigning, idet der ved 11.605 forespørgsler pr time er svartiden 58708.9 ms,
altså 58.7 s.
$np$
Kurvens forløb viser derfor tydeligt, at der findes en lodret asymptote, der
ligger omkring 12.000 forespørgsler pr time. Det er ikke muligt at undersøge dette
nærmere ved simulatoren, idet ved en belastning på 13.000 forespørgsler opstår
så lange kølængder, at simulatoren ikke kan køre. Dette skyldes, den begrænsede
lagermængde man får tildelt ved kørsler på RECKU.
$np$
Ud fra kurven kan således påstås, at en RC8000 koblet til OP-systemet maksimalt
kan behandle op til 12.000 forespørgsler pr. time.(RC8000 kapacietet) Ved denne belastning vil
svartiden i RC8000 være så stor, at det vil være til
irritation for tasteoperatørerne.
$ps$
$ps$$ps$
$np$
Svarende til denne kurve vil det være særdeles interessant, at betragte
belastningen af CPU-en.
Figur 6.3.2 viser, hvordan CPU-udnyttelsen afhænger af antallet af forespørgsler pr. time.
Udnyttelsesgraden af CPU-en er fundet ved at summere CPU-udnyttelsen fra de
4 processer, og udnyttelsen af monitoren.
Det bør her bemærkes, at udnyttelses
af monitoren er fundet under den forudsætning, at det tager 1.5 ms at skifte mellem
to processer. Det viste sig, at med denne skiftetid blev resultaterne fra simulatoren
mest nøjagtig.
Ud fra målinger i logfilen ved meget
små belastninger kan ses, at når en forespørgsler passerer mellem to processer, vil denne skiftetid være større. Antallet af gange en forespørgsel skifter
mellem to processer kan ved en belastning på 5733 findes til 12.931. Svarende til
en belastning på 6142 forespørgsler er antallet af processkift i simulatoren målt
til 131.893. Dvs. at antallet af processkift stammende fra, at monitoren skifter
den kørende proces på grund af enten processen ønsker pladelager eller processen
bliver afbrudt af et tidsinterrupt, dermed er
væsentligt større end processkift stammende fra
at en forespørgsel skifter mellem to processer. Det antages derfor, at
udnyttelsesgraden af monitoren ved simulatoren beregnes rigtigt.
$np$
Kurven figur 6.3.2 viser nu ud af X-aksen antallet af forespørgsler pr. time og op ad
Y-aksen angives udnyttelsesgraden af CPU-en. Kurven tilnærmer sig en lineær
funktion.
For at finde, hvilken linie der er tale om er den gennemsnitlige CPU-tid
for en forespørgsel samlet for de 4 processer beregnet. Dette er fra den
24.04.81 fundet til 273.0 ms. På figur 6.3.2
er den stiplede linie tegnet ud fra dette CPU-forbrug. Linien er
tegnet ud fra følgende formel:

$sj$
antalforsp * 273.0 ms
______________________ *100
60 * 60 * 1000
$rj$
$np$
Svarende til denne linie vil en udnyttelse på 100 % af CPU-en opnås ved
13160 forespørgsler pr. time. Det virker dog særdeles rimeligt, at en RC8000
ikke kan behandle dette antal, da de indgående kølængder bliver for store.
Med den konstruktion som OP-systemet idag har på en RC8000, kan det således påstås,
at en udnyttelse på CPU-en på 100 % ikke kan forekomme.
Udnyttelsen svarende til en belastning på 11605 forespørgsler pr. time
er 68.8 %.
$np$
For at komme med forbedringsforslag til OP-systemet er det nødvendigt at betagte
andre størrelsers afhængighed af belastningen.
Det viser sig, at køtiden ved søgeprocessen har den kraftigste stigning i forbindelse
med at belastningen øges. Figur 6.3.3 viser, hvorledes køtiden ved søgeprocessen
afhænger af belastningen. X-aksen angiver antallet af forespørgsler pr time og
Y-aksen angiver køtiden i ms. Køtiden er ved en belastning på 10048 forespørgsler
1791.2 ms. Dette er større end den gennemsnitlige svartid som ved samme belastning er 1653.4 ms.
Til dette kan anføres, at ikke alle forespørgsler er søgeforespørgsler (kun 66 %), og andre forespørgselstyper vil ikke stå i kø til søgeprocessen. En tlfnrforespørgsel vil ved en tilsvarende belastning kun stå i kø til opslagsprocesen
i 35.5 ms.

Ved køtiden i opslagsprocessen er
simulatoren ikke så nøjagtig som den
burde(se simulatoropgaven). Målinger har vist køtiden ved opslagsprocessen skal være væsentlig
større.
$np$
Til kurven på figur 6.3.3 kan tilføjes,
at kølængden ved søgeprocessen stiger tilsvarende.
Ved en belastning på 5020 forespørgsler pr. time er den gennemsnitlige kølængde
til søgeprocessen
på 1.8 og ved en belastning
på 11605 forespørgsler pr. time er kølængden 199.0. Et forbedringsforslag til systemet vil
på baggrund af de indtil nu anførte kurver skulle være at forbedre søgeproccessen.
$ps$
$ps$
$np$
Inden egentlige forbedringsforslag anføres vil det blive beskrevet, hvorledes systemet præcist opfører sig ved en
en belastning på hhv. 6000,8000 og 10.000 forespørgsler pr time.
Tabel 6.3.1 viser de mest betydende størrelser, når belastningen øges.
$sj$
antal forsp.pr.time 6000 8000 10.000

procestid søge 452.2 ms 460.8 ms 466.9 ms
-"- opslag 176.1 ms 184.9 ms 193.2 ms
køtid søge 318.1 ms 607.3 ms 1791.2 ms
-"- opslag 20.7 ms 26.5 ms 35.5 ms
Gnst. svartid 657.8 ms 868.9 ms 1653.4 ms
Udnytg. input 2.78 % 3.66 % 4.55 %
-"- søge 20.42 % 26.93 % 32.49 %
-"- opslag 6.92 % 9.17 % 11.26 %
-"- output 1.54 % 2.03 % 2.53 %
-"- monitor 5.50 % 7.19 % 8.75 %
-"- diskkanal 15.50 % 20.54 % 25.75 %
-"- søgedisk 22.53 % 29.65 % 36.21 %
-"- opslagdisk 7.16 % 9.12 % 11.04 %
-"- outputdisk 0.18 % 0.24 % 0.32 %
-"- CPU 37.16 % 48.99 % 59.75 %

kølængde input 0.043 0.063 0.086
-"- søge 0.862 1.59 4.15
-"- opslag 0.203 0.233 0.380
-"- output 0.025 0.035 0.047
-"- diskkanal 0.160 0.212 0.262

minimal svartid 28.31 ms 28.31 ms 28.31 ms
maksiaml svartid 5137.66 ms 5949.3 ms 12147.3 ms

97 % af forsp. 2249 ms 2999 ms 6750 ms

tabel 6.3.1
$rj$$np$
Den sidste linie i tabellen angiver, hvornår 97 % af forespørgslerne er
besvaret.
Det kan bemærkes,
at udnyttelsen af søge- og opslagdisk er noget mindre end de målte. Dette skyldes
at antallet af diskaccesser ikke helt stemmer overens. Ved simulatoren er der således 12.5
diskaccesser ved søgedisken mod en beregnet størrelse på 13.9.
Når nogle forbedringsforslag skal opstilles, bør disse sigte mod at formindske
de størrelser, der har størst stigning
ved en forøgelse af antallet af forespørgsler pr. time.
Dvs. køtiden ved søgeprocessen.
Til en RC8000 kan stilles nogle forbedringsforslag der simpelt
kan implementeres ved en RC8000. Disse forslag går dels ud på at prioritere søgeprocessen højere end de
andre processer og dels ud på at dublere pladelagerkanalen.
$np$
Ved at opprioritere søgeprocessen opnås, at hver gang en forespørgsel
findes ved søgeprocessen vil denne blive behandlet. Ved hjælp af simulatoren har det
vist sig, at dette ikke giver nogen væsentlig forbedring af udnyttelsen af en RC8000.
Det har endda vist sig, at den gennemsnitlige
svartid stiger. At svartiden stiger kan forklares ved, at de andre processer ikke
kan behandle forespørgslerne så hurtigt.
Resultaterne fra kørslene er angivet i tabel 6.3.2. Procestiden og køtiden
ved søge processen formindskes lidt, hvorimod køtiden og procestiden ved de andre processer forøges. Konkluderende må dog anføres, at en prioritering
af søgeprocessen ikke bevirker, at systemet opførsel bliver bedre.
$sj$
4000 4000 6000 60000
uden prio. med prio. uden prio. med prio.
procestid søge 432.8 ms 424.0 ms 452.2 ms 440.3 ms
-"- opslag 165.4 ms 171.0 ms 176.1 ms 184.9 ms
Køtid søge 130.8 ms 128.6 ms 318.1 ms 254.1 ms
-"- opslag 12.5 ms 14.4 ms 20.7 ms 24.4 ms
gnst. svartid 516.5 ms 519.7 ms 657.8 ms 620.2 ms
Udnytg. af CPU 24.0 % 24.5 % 37.2 % 36.7 %

tabel 6.3.2

$rj$$np$
Et andet forbedringsforslag, som specielt har interesse hos KTAS er at
dublere datakanalen, idet man råder over
en ekstra datakanal.
Ved en belastning på
4000 og 6000 forespørgsler pr. time er resultaterne fra kørsler med en dubleret
pladelagerkanalen vist i tabel 6.3.3.

$sj$
4000 4000 6000 6000
uden dub. med dub. uden dub. med dub.

procestid søge 432.8 ms 427.1 ms 452.2 ms 448.5 ms
-"- opslag 165.4 ms 166.8 ms 176.1 ms 174.6 ms

køtid søge 130.8 ms 134.5 ms 318.1 ms 307.6 ms
-"- opslag 12.5 ms 11.2 ms 20.7 ms 18.8 ms

gnst svartid 516.5 ms 504.8 ms 657.8 ms 646.1 ms

Udnytg.diskkan1. 7.64 % 11.73 %
Udnytg.diskkan2. 2.59 % 3.86 %
Udnytg.diskkanal 10.21 % 15.59 %
Udnytg. CPU 23.93 % 24.06 % 37.16 % 37.39 %

tabel 6.3.3
$rj$
$np$
Dubleringen af datakanalen er foretaget, så søgedisken er koblet
til den ene kanal og opslags- og outputdisken er koblet til den anden kanal.
Resultaterne viser, at gevinsten ved at have to datakanler er særdeles lille.
Den gennemsnitlige svartid bliver mindre ved, at procestiden ved søgeprocessen formindskes lidt.
Intuitivt er det klart, at en dublering af datakanalen ikke
vil give den helt store forbedring.
Dette skyldes, at datakanalen ikke er udnyttet i mere end ca.
16.4 % af tiden ved en størst målte belastning. Der vil derfor ikke ske en
forsinkelse af en forespørgsel ved at den står i kø til datanalen.
$np$
For at komme med et forslag,
der virkelig forbedre systemet,
er det nødvendigt at betragte,
hvordan tiden forløber i søgeprocessen.
På figur 6.3.4 er angivet et tidsdiagram
over, hvordan tiden forløber i en RC8000.
Til figuren er foretaget en del begrænsinger.
Begrænsningerne er, at CPU-tiden er afrundet til et helt tal for at kunne
tegne tidslinien. På figuren er vist en tidslinie for hver proces og for
CPU-en. En skravering af tidslinien angiver, at pågældende proces er kørende.
For CPU-en er tegnet en sort kasse til at angive, når CPU-en er ledig.
Det
antages at den gennemsnitlige CPU-tid i søgeprocessen er 180 ms, og at der er
14 pladelagertilgange i søgeprocessen.
Mellem to pladelagertilgange er så 180:15 =12 ms.
En pladelagertilgang antages at tage 18 ms.
Tiden der benyttes til pladelageret i søge processen er således 14 * 18 = 252 ms.
$np$
Hvis nu søgeprocessen var den eneste proces, der benyttede CPU-en ville
den maksimale udnyttelse være 41.6 %. (180 ms ud af 180+252=432 ms).
Med andre ord venter CPU-en i 58.4 % af tiden på en pladelagertilgang er
færdig.
Ved at programmere OP-systemet i form af 4 processor er det muligt at udnytte nogle
af disse 58.4 % til behandling af forespørgsler ved de andre processer. Hvis det
antages,
at en forespørgsel benytter 66 ms ved opslagsprocessen, og systemet behandler en forespørgsel
ved opslagsprocessen hver gang en forespørgsel behandles ved søgeprocessen så
når man op på en udnyttelse af CPU-en på 56.9 % (180+66 = 246 ms ud af 432 ms).
Hvis det derudover antages,
at input- og outputprocessen også behandler en forespørgsel indenfor tidsrummet
og de benytter hhv 16 og 9 ms, så opnås en CPU-udnyttelse på 62.7 %.
$np$
En forøgelse af udnyttelse af CPU-en kan nu kun foregå ved at opslagsprocessen
behandler en tlfnr.forespørgsel.
Dette er på figuren angivet med rødt.
Hvis det antages, at den bruger 66 ms i opslagsprocessen,
og hhv. 16 og 9 i input- og outputprocessen så opnås en maksimal udnyttelse
på 83.8 %. Dvs. den maksimale udnyttelse af CPU-en til en RC8000 til
OP-systemet er omkring
83.8 %.
$ps$$ps$
$np$
Det er ikke muligt, at en så stor udnyttelse kan foregå over en længere periode,
idet dette kræver at der kommer lige så mange tlfnr.forespørgsler som søgeforespørgsler.
$ns 1,4,_«bs»6_«bs»._«bs»3_«bs»._«bs»3_«bs»._«bs»D_«bs»u_«bs»b_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»s_«bs»ø_«bs»g_«bs»e_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np$
En drastisk forøgelse af udnyttelsen af CPU-en vil på baggrund af forrige afsnit
forekomme ved,
at søgeprocessen behandler mere end en forespørgsel ad gangen. At
implementere at søgeprocessen skal kunne behandle mere end en forespørgsel
ad gangen vil være lettest ved at dublere søgeprocessen. Hver
søgeproces kan så behandle en forespørgsel på samme tid.
$np$
Ved en dublering af søgeprocessen er det naturligt, at der kun opnås
en fordel, når belastningen af systemet er over et vist punkt.
Svarende til en belastning på ca. 6000 forespørgsler pr. time formindskes
den gennemsnitlige svartid fra 657.8 ms til 542.5 ms ved en dublering
af søgeprocessen.
$np$
Figur 6.3.5 viser, hvordan svartiden (angivet ud af Y-aksen) er en funktion
af antallet af forespørgsler pr. time (angivet ud af X-aksen). Kurven viser ikke en
så stejl stigning for svartiden ved foreøgelse af belastningen som uden dublering af søgeprocessen(angivet som stiplet linie).
Når OP-systemet betragtes ved en belastning på 6000 forespørgsler vides,
fra målinger i logfilen, at 97 % af samlige forespørgsler besvares under 2 s.
Ved en dublering af søgeprocessen vil 97 % af forespørgslerne kunne besvares
under 2 s ved en belastning på 7959 forespørgsler.
Ved denne belastning vil den gennemsnitlige svartid være 663.2 ms.
$ps$$ps$
$np$
Der anvendes til OP-systemet i meget belastede timer 3 RC8000, svarende til
at de 3 maskiner behandler ca 13.000 forespørgsler. Forespørgslerne
fordeles således, at en RC8000 modtager omkring 6000 forespørgsler. Dette
bevirker en svartid der lige kan accepteres. Ved at dublere søgeprocessen vil det være
muligt med 2 RC8000 at behandle samme antal forespørgsler under samme betingelser
som forespørgslerne idag behandles med 3 maskiner.
$np$
Figur 6.3.6 viser, hvordan CPU-udnyttelsen er ved en dubleret søgeproces,
og den stiplede linie angiver, hvordan udnyttelsen er uden dublering.
Hvert punkt til dubleringen er angivet i en cirkel.
Figuren viser, at CPU-udnyttelsesgraden ved belastninger på under 8000
forespørgsler pr. time faktisk er den samme for de to typer. Dette
kan forklares ved, at CPU-en behandler det samme antal forespørgsler.
Den lille forøgelse af CPU-udnyttelsen stammer fra, at der er sket en formindskelse i svartiden. Figuren viser ved belastninger på over 8000 forespørgsler
er det muligt at udnytte CPU-en mere ved dublering af søgeprocessen.
$ps$$ps$
$np$
Da søgeprocessen er den proces, der optager mest plads i RC8000, vil det
formentlig være en ret kostbar affære at dublere søgeprocessen. Det kræver
udover en programændring en udvidelse af lageret koblet til en RC8000. Et
andet forslag til forbedring af OP-systemets RC8000- del kan så gives
ud fra et dybere kendskab til søgeprocessen.
$np$
Søgeprocessen fungere således, at den ud fra hvert kriterie i en søgeforespørgsel
danner en mængde af kandidater. For at finde frem til eventuelle kandidater
findes fællesmængden af disse kandidater.
$nl2$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l
$nl$
Antag at følgende søgeforespørgsel bliver stillet
$sj$

*bFrederikssund *nLarsen *fKnud
$rj$
$nl2$

Ud fra første kriterie *bFrederikssund slås op i en tabel
kaldet hypp.tabellen over stednavne. Her findes alle hyppigt
brugte stednavne. Fra en OPSTAT vides, at ca. 82 % af alle
stednavne findes i denne tabel. I tabellen er der ved stednavnet
angivet en pointer til en tabel kaldet AB-tabellen og
to pointere til en fil kaldet navnesøgefil. I AB-tabellen
findes en pointer til abonnentfilen. Abonnentfilen indeholder information om
telefonabonnenter.
$np$
Ud fra andet søgekriterie *nLarsen findes ved hjælp af Larsen en pointer
i en navneindeksfilen. Denne fil indeholder pointere til navnesøgefil,
hvor navne findes opdelt efter område.
På figur 6.3.7 er de forskellige filer og pointere angivet.
$ps$$ps$
Figuren er noget simplificeret,
så der kun er medtaget to søgekriterier.
Det vigtigste
at observere er, at ud fra stednavnet opnås en pointer til
abonnentfilen og ud fra efternavnet opnås to pointere i abonnentfilen.
De kandidater som søgekriteriet giver adgang til bliver en mængde af pointere i abonnentfilen,
og ud fra denne dannes en fællesmængde svarende til de enkelte søgekriterier.
$np$
Undersøgelsen med en dubleret søgeproces viste, at dette bevirkede en bedre
udnyttelse af CPU-en. Dette skyldes, at det var muligt at behandle mere
end en forespørgsel ved søgeprocessen. Formålet med ovenstående
beskrivelse er, at beskrive at denne effekt også kan opnås ved at opspalte
søgeprocessen i mere end en proces.
$np$
Dette kunne gøres ved at lave en proces, der svarer til et
eller to kriterier, og derefter en anden proces, der
svarer til resten af søgekriterierne. Ud fra en OPSTAT
kan kriteriesammensætningen findes. Det viser sig, at udover stednavnet er det mest
anvendte kriterie efternavnet.
$np$
Udfra dette vil jeg så foreslå følgende opdeling af søgeprocessen.
Der laves to søgeprocesser. En søgeproces behandler stednavnet og
et gadenavn og husnr. De sidste kriterier er søgekriterier, som
ikke er de mest anvendte, men det forekommer i omkring 53.3 % af
søgeforespørgsler. Tallet 53.3 % er opnået fra en OPSTAT. Den anden
søgeproces skal derefter behandle resten af søgekriterierne.
OP-systemet i RC8000 vil derefter få udseendet vist på figur 6.3.8.
$fg 120$
De nye veje for en forespørgsel er på
figuren markeret A,B,C,D og E.
Det er ikke muligt præcist at angive, hvor stor en procentdel der vil passere
gennem de enkelte veje. Ved at betragte en OPSTAT vides, at en søgeforespørgsel
i gennemsnit tager 703 ms. En forespørgsel, hvor stednavnet ikke findes
tager i gennemsnit 272 ms.
$np$
De forespørgsler, der behandles i søgeproces 1 er forespørgsler på
stednavn,gade og husnr.
Det er ikke muligt at angive, hvormeget tid søgeproces 1 skal anvende,
men det vil formentlig
ligge omkring tiden for en afvist forespørgsel, hvor stednavnet ikke
findes.
Antallet af pladelagertilgange i søgeproces 1 kan ikke findes, men det kan
maksimalt være (0.18 +(2*2*3.5)= 12.68 pr. forespørgsel, fundet
ud fra formlen angivet i afsnit 3). Da de to søgekriterier kun findes for
53.3 % af forespørgslerne, vil antallet af pladelagertilgange
i søgeproces 1 formentlig være omkring (53.3 * 12.68)/100= 6.8 pr. forespørgsel og
dermed omkring 7.2 i søgeproces 2. Formålet med opdelingen
er, at dele processerne således at de vil have samme arbejdsbyrde pr.
forespørgsel. Ved dette vil der opstå en vekselvirkning mellem CPU-behandling
i den ene proces og pladelagertilgange. Dette kan illustreres på nedenstående
figur.
$fg 60$
På figuren er forholdene beskrevet optimalt, men ved en opdeling
på tilsvarende måde vil en højere udnyttelse af CPU-en kunne opnås.

$np$
Det angivne skal således kun ses som et forslag til, hvordan en opdeling
kan gøres. Det vil dog kræve en meget dybtgående undersøgelse
af hvordan kriteriesammensætningen for en søgeforespørgsel
er og hvilket tidforbrug de enkelte søgekriterier har, før en
anvendelig opdeling kan foretages godt.
$ns 1,4,_«bs»6_«bs»._«bs»3_«bs»._«bs»4_«bs»._«bs»I_«bs»n_«bs»d_«bs»f_«bs»ø_«bs»r_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»h_«bs»u_«bs»r_«bs»t_«bs»i_«bs»g_«bs»e_«bs»r_«bs»e__«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0_«bs».$
$np$
Efter konstruktionen af OP-systemet har RC udviklet
en hurtigere RC8000. Denne RC8000 betegnes model 55. Forskellen fra den ved
OP-systemet benyttede RC8000 er, at der til denne findes et "cache" lager.
En beskrivelse for hvad et "cache" lager er, og hvordan det fungerer findes
i Tan76 side 263-264.
Dette
bevirker, at maskinen ca. bliver dobbelt så hurtig. Anskaffelsesprisen for en
sådan maskine er ikke svarende til en ny, fordi det kun er nødvendigt
at anskaffe et "cache" lager.
$np$
Ved at halvere tidsforbruget ved de enkelte processer og monitorskiftetiden
er der nu foretaget en række simulationskørsler.
$np$
Tabel 6.3.4 viser en sammenligning af de 3 betragtede modeller af OP-systemet.
$ps$
$sj$
almindelig dubleret søgeproc. RC8000/55
antal forsp.pr.time 6142 5989 5998
procestid søgeproces 452.2 ms 516.8 ms 315.9 ms
-"- opslagsproc. 176.1 ms 185.0 ms 121.3 ms
køtid søgeproces 318.1 ms 59.1 ms 97.1 ms
-"- opslagsproc. 20.7 ms 29.1 ms 8.0 ms
Gnst. svartid 657.8 ms 542.5 ms 366.3 ms
Udn.grad af søgedisk 22.7 % 22.2 % 22.1 %
-"- opslagsdisk 7.2 % 6.9 % 6.9 %
-"- datakanal 15.6 % 15.2 % 15.2 %
-"- CPU 37.2 % 35.9 % 17.7 %

tabel 6.3.5.
$rj$$np$
Tabellen viser en meget tydelig tidsgevinst i den gennemsnitlige svartid
ved anskaffelsen af en model 55. De indgående diske bliver udnyttet ligemeget
ved de tre modellen. Det vil derfor være interessant at se om disse
diskes udnyttelse ved en model 55 får indflydelse for, hvor stor en
belastning en RC8000 kan klare. Det vil dog først blive vist, hvor stort
et antal forespørgsler en model 55 kan behandle under de samme forudsætninger,
som en almindelig RC8000 kan ved en belastning på 6000 forespørgsler pr. time.
Det er valgt at betragte denne belastning, idet den kan opfattes som
et mål for, hvor store svartider man vil aksepterer hos KTAS.
$np$
Tabel 6.3.6 viser nu, de vigtigste størrelse for en model 55 ved en belastning
på ca. 12000 forespørgsler pr. time sammenlignet med en model 45 ved 6000 forespørgsler pr. time.
$ps$
$sj$
model 45 model 55
antal forsp 6142 11952

Procestid søge 452.2 ms 325.4 ms
-"- opslag 176.1 ms 129.2 ms

Køtid søge 318.1 ms 454.1 ms
-"- opslag 20.7 ms 17.9 ms

Gnst svartid 657.8 ms 619.0 ms

Udnyttelse af søgedisk 22.5 % 43.6 %
-"- opslagdisk 7.2 % 13.3 %
Udnyttelse af diskkanal 15.6 % 30.3 %

Udnyttelse af CPU 37.2 % 34.9 %

tabel 6.3.6

$rj$
$np$
Tabellen viser, at en model 55 faktisk ved en belastning på
6000 forespørgsler til en model 45 kan klare ca. dobbelt så
mange forespørgsler med samme svartid. Dette giver anledning til en
del forundring. Man skulle tro at andre størrelse end
hastigheden af CPU-en har indflydelse på,
hvordan svartiden for forespørgslerne er.
At en model 55 kan behandle dobbelt så mange forespørgsler som en model 45
betyder, at man ved KTAS kan nøjes med at anvende 2 RC8000 til OP-systemet
i en hårdt belastet time. Derved kan samtlige forespørgsler besvares under
samme betingelser som det gøres nu med 3 RC8000. Der vil ved en model 55
være mindre svartider, og hvis antallet af forespørgsler forøges vil en
to maskiner kunne behandle ca. 24000 forespørgsler pr. time. Disse maskiner
vil således dække behovet et godt stykke ud i fremtiden.
$np$
For nærmere at belyse om, hvordan
svartiden afhænger af
belastningen, er dette anført på figur 6.3.10.
På figur 6.3.10 er den stiplede kurve tegnet for en model 45. Figuren viser,
at en model 55 bevirker, at den gennemsnitlige svartid formindskes væsentligt.
Derudover bliver kapacitetet (absissen for den lodrette asymptote) forøget.
Kurven viser, at CPU-ens hastighed har meget stor indflydelse på behandlingen
af forespørgsler. Imidlertid har CPU-en hastighed ikke så stor
indflydelse på behandlingen af forespørgsler at en fordobling af
CPU-hastigheden bevirker, at en RC8000 maksimalt kan behandle dobbelt
så mange forespørgsler. Derimod ligger kapaciteten for en model 55
på ca. 17000 forespørgsler pr. time. Ved denne belastning er den
størst udnyttede enhed søgedisken, som er udnyttet i 58.8 % af tiden.
CPU-en er kun udnyttet i 48.0 % og datakanalen er udnyttet 41.5 %.
Ved store belastninger på en model 55 vil det derfor være naturligt
at anskaffe en hurtigere søgedisk og eventulet dublere diskkanalen.
$ps$$ps$
$ns 1,4,_«bs»6_«bs»._«bs»4_«bs»._«bs»T_«bs»e_«bs»o_«bs»r_«bs»e_«bs»t_«bs»i_«bs»s_«bs»k__«bs»a_«bs»n_«bs»a_«bs»l_«bs»y_«bs»s_«bs»e__«bs»a_«bs»f__«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».$
$np$
Nedenstående afsnit beskriver 2 normalt anvendte metoder til teoreisk analyse
af et datamatisk system. Den første tager udgangspunkt i at finde antallet
af terminaler, der kan kobles til systemet. Den anden angiver en metode, hvormed
en
flaskehals ved et system kan findes.
$nl2$
_«bs»1_«bs»._«bs»V_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»t_«bs»e_«bs»r_«bs»m_«bs»i_«bs»n_«bs»a_«bs»l__«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs».
$nl$
En model svarende til nedenstående figur betragtes.
Systemet består af n terminaler og en CPU. Ved terminalerne sendes et job (forespørgsel).

Tiden mellem to forespørgsler er en variabel størrelse og betegnes tænketiden.
Dvs. en person ved en terminal tænker et vist
stykke tid, når svaret på en sendt forespørgsel er modtaget
inden næste transaktion sendes.
$fg 100$
Det forudsættes, at tænketiden er eksponetial fordelt med middelværdi
1/^^.
En anden størrelse som skal kendes ved denne model
er den gennemsnitlige behandlingstid for et
job under forudsætning af,
at dette job befinder sig alene ved CPU-en. Behandlingstiden forudsættes ligeledes eksponentialfordelt med middelværdi 1/^^.
Under disse forudsætninger kan det vises, at middelsvartiden er en funktion af antallet
af terminaler, og dens forløb vil være som vist på nedenstående figur.
Ud af X-aksen er angivet antallet af terminaler og Y-aksen angiver den
gennemsnitlige svartid.
$fg 80$
Kurven på figuren vil have to asymptoter en vandret og en skrå.
$np$
Den vandrette asymptote kan bestemmes ved den minimale svartid. Når
antallet af terminaler går mod 0 så vil den gennemsnitlige svartid pr. terminal
gå mod 1/^^.
Ligningen for den vandrette asymptote vil så være y = 1/^^.
Ligningen for den skrå asymptote kan bestemmes ud fra ^^,^^ og N
antallet af terminaler. Den skrå asymptote er givet ved ligningen
$sj$

N/ - 1/
$rj$$np$
Absissen for skæringspunktet mellem disse asymptoter betegnes mætningspunktet. Dette angiver
det antal terminaler, hvorom det kan siges, at hvis flere terminaler kobles til
systemet så vil der opstå kø ved CPU-en. Mætningspunktet kan bestemmes ved følgende formel:
$nl5$
$nl$
Ovenfor anførte betragtninger findes
i Brin 73 side 214-221, Ferr78 side 210-212 og Denn 78 side 239-243.
Hos Denn78 er fortolkningen af mætningspunktet fundet.
$np$
Denne model vil nu blive anvendt til at finde mætningspunktet for en RC8000 ved OP-systemet.
De to indgående størrelser findes efter følgende princip:
$nl2$
_«bs»1_«bs»._«bs»G_«bs»e_«bs»n_«bs»n_«bs»e_«bs»m_«bs»s_«bs»n_«bs»i_«bs»t_«bs»l_«bs»i_«bs»g__«bs»b_«bs»e_«bs»h_«bs»a_«bs»n_«bs»d_«bs»l_«bs»i_«bs»n_«bs»g_«bs»s_«bs»t_«bs»i_«bs»d_«bs».
$nl$
Denne størrelse skal findes under forudsætning af, at en forespørgsel befinder
sig alene i RC8000. Til dette findes fra KTASSTAT den time,
der har været mindst
belastning. Ved en belastning på 36 forespørgsler pr. time er den gennemsnitlige svartid
i RC8000 413.9 ms.
$nl2$
_«bs»2_«bs»._«bs»G_«bs»e_«bs»n_«bs»n_«bs»e_«bs»m_«bs»s_«bs»n_«bs»i_«bs»t_«bs»l_«bs»i_«bs»g__«bs»t_«bs»æ_«bs»n_«bs»k_«bs»e_«bs»t_«bs»i_«bs»d_«bs».
$nl$
Antallet af terminaler koblet til systemet i en hårdt belastet time er 130, og den
hårdest belastede time svarer til,
at der afsendes 13107 forespørgsler. Ud fra dette
kan den gennemsnitlige tænketid pr sekund beregnes til:
$sj$
130*60*60
= _________ = 35.7
13107

$rj$
$ps$$ps$
Ud fra dette beregnes mætningspunktet for en RC8000 til :
$sj$
* 35.70
N = 1 + ______ = 87 terminaler.
0.4139
$rj$
$np$
Ud fra disse betragtninger kan antallet af forespørgsler der afsendes pr. time
pr. terminal findes. Dette findes ved:
$sj$

60 * 60
_______ = 108.4 transaktioner pr. time pr. terminal
35.6
$rj$$np$
Hvis der kobles 87 terminaler til en RC8000 så vil antal tranaktioner
pr. time maskinen modtager være
$sj$

87 * 108.4 = 9431 transaktioner pr. time
$rj$$np$
Ved dette antal transaktioner har simulatoren vist at den gennemsnitlige
svartid være ca. 1500 ms. Ved nu at antage, at den gennemsnitlige tænketid
ved terminalerne altid er 35.7 pr. sekund kan kurven på figur 6.4.3 tegnes.
Punkterne til kurven findes ved at x terminaler afgiver ((60*60)/35.7)* x
forespørgsler pr. time. Fra simulatoren vides, hvordan den gennemsnitlige svartid er, når
antallet af forespørgsler pr. time kendes.
$np$
Den derved opnåede kurve vil så være kurven svarende til figur 6.4.3. På
figur 6.4.3 er de to asymptoter angivet. Kurven viser, at et
punkt svarende til 100 terminaler har
en større svartid end den skrå asymptote angiver. Dette skyldes formentlig
følgende begrænsning i simulatoren. Ved et terminal system vil forespørgsler fra
en terminal først blive afsendt, når svaret på forrige forespørgsel er modtaget.
Der tages imidlertid ikke højde for dette ved simulatoren, da der her anvendes et fast
ankomstmønster. Dette skyldes, at simulatoren kun afbilder RC8000-delen af OP-systemet.
Hvis kurven for svartiden fortsættes sker en særdeles kraftig stigning ved 11605 forespørgsler pr. time(svarer til ca. 107 terminaler). Det virker
derfor sandsynligt, at kurven vil tilnærme sig den anførte skrå asymptote.

$nl2$
2.Kømodeller.
$np$
Det anføres her ud fra en teoretisk model, hvordan en flaskehals til systemet
kan findes. For at kunne gøre dette betragtes en kønetværksmodel af
systemet. Kømodellen er angivet på figur 6.4.4.
Den findes beskrevet i Buze71.
$fg 90$
Systemet har 1 CPU og L ydre enheder.
I forbindelse med anvendelsen her er L = 3, og de ydre enheder er hhv. søge- , opslags- og outputdisk. Til
modellen anføres nogle sandsynligheder p0,...,pL. pi angiver sandsynligheden
for, at et job, når det har afsluttet en behandling ved CPU-en, skal behandles ved enhed i.
Et job betegnes som færdigt, når det har afsluttet en CPU-behandling, og
ikke skal benytte en af de ydre enheder. p0 angiver således sandsynligheden for, at jobbet er
færdigt. Efter at jobbet er færdigt bliver det sat i kø til CPU-en, og dette
angiver, at et nyt job starter i systemet.
$np$
Et job består således af en række forløb bestående af
et CPU-tidsinterval efterfulgt af en behandling ved en ydre enhed.

Summen af pi'erne er 1.
$np$
Der er både til CPU-en og de ydre enheder knyttet en kø. Det antages, at antallet
af job, der befinder sig i systemet er konstant, og det betegnes N.
$np$
Behandlingstiden ved de indgående enheder antages at være eksponentialfordelt med
middelværdi ui. Den gennemsnitlige behandlingstid ved enhed i er så 1/ui.
$np$
Inden en flaskehals defineres vil en række
ting blive fremhævet.
$np$
Med Ai betegnes sandsynligheden for, at enhed i er aktiv.
Dvs. at Ai kan opfattes,
som den del af observationsperioden, hvor enheden er optaget(Ai er således udnyttelsesgraden af enhed i).

Ao er sandsynligheden for, at CPU-en er optaget.
$np$
Man er interesseret i at beregne det forventede antal job, der færdiggøres
over en tidsperiode af længden T. CPU-en vil her være optaget i Ao*T.
$np$
Et job afvikles ved CPU-en i et antal tidsintervaller. Det gennemsnitlige
antal CPU-tidsintervaller pr job er 1/po, fordi sandsynligheden for at
et program vil afslutte efter et CPU-tidsinterval er po. Den gennemsnitlige
behandlingstid for et CPU-tidsinterval er 1/uo. Dvs. at et job i gennemsnit
benytter CPU-en i 1/uo*1/po= 1/uopo.
$np$
Dermed kan det gennemsnitlige antal afviklede job over tidsperioden T findes til
$sj$

Ao*T*uopo
$rj$$nl$
Dermed vil afviklingen pr tidsenhed være
$sj$
(1) Ao*uo*po
$rj$$nl$
Hvert jobs sandsynlighed for at modtage behandling
ved enhed i er pi. Da Ao angiver sandsynligheden for, at CPU-en er optaget, og
1/uo angiver den gennemsnitlige behandlingstid pr job ved CPU-en, vil
Ao*uo være et mål for, hvor tit et job er færdig med et CPU-tidsinterval.
Det forventede antal job, som skal behandles ved enhed i er derfor
$sj$
Ao*uo*pi
$rj$
$np$
Omvendt er Ai sandsynligheden for, at enhed i er aktiv og ui er behandlingsraten
ved enhed i.

Dvs. Ai*ui er antallet af job afviklet ved enhed i. Da antallet af job afviklet ved
enhed i er det samme som antallet af ankommende job til enhed i, så gælder
$sj$
Ao*uo*pi = Ai*ui
og dermed
Ao*uo = Aiui/pi.
$rj$$nl$
Systemets gennemstrømning defineres som det gennemsnitlige antal job,
der færdiggøres pr tidsenhed.
Et udtryk for gennemstrømningen kan nu opstilles ved brug af (1).
Derved fås
$sj$

Ao*uo*po = Ai*ui*po / pi
$rj$$nl$
En flaskehals defineres i Buze71 som den enhed i systemet, der bevirker en alvorlig
formindskelse i systemets ydeevne. Denne definition kan nu omformuleres til:
$nl$
Hvis en lille forøgelse i en enheds gennemstrømning bevirker en stor forøgelse
i systemets gennemstrømning, så er pågældende enhed en flaskehals.
$np$
Hele systemets gennemstrømning er Ao*uo*po og enhed i skaber en derfor en flaskehals,
hvis
^(Ao*uo*po)/^^ui er stor. Når en flaskehals skal findes skal den maksimale af
disse partielle afledede findes.
Ao er en funktion af uo,u1,...,uL,po,p1,...,pL, og N.
$np$
Den definition, der ofte anvendes på en flaskehlas, nemlig at en flaskehals
er den enhed med størst udnyttelse, kan man vise (se Buz71 side 98-100) gælder
i det tilfælde, hvor de indgående sandsynligheder er valgt optimalt.
$np$
Ved OP-systemet er det imidlertid ikke muligt at angive om de indgående
sandsynligheder er optimalt valgt. Derudover er det meget vanskeligt at finde
de partielle afledede. Dette er faktisk kun muligt ved hjælp af simulatoren.
$np$
Ved hjælp af simulatoren er det endda ikke muligt præcist at angive,
hvordan de partielle afledede er for alle belastninger. Derimod
er det muligt at finde de partielle afledede svarende til en fast
belastning. Dette gøres på følgende måde:
$np$
En belastning på ca. 4000 forespørgsler betragtes. Svarende til denne belastning
varieres nu på hastigheden af de indgående enheder. Derved kan de partielle afledede
for de indgående enheder findes. Figur 6.4.5 viser tre linier stammende fra
at hhv. CPU-en,søge- og opslagsdiskens hastighed er variaret. De er opnået ved at
gøre den til linien svarende enhed hhv. 25 % hurtigere og 25 % langsommere end enheden
normalt er. På figuren er det præstationsindeks, som ønskes forbedret dvs. den
gennemsnitlige svartid, anført ud af Y-aksen.
X-aksen angiver et mål for ændringen i hastigheden på en enhed. X = 1 er
den hastighed enheden har ved OP-systemet. Punktet X=1.25 svarer til at
hastigheden for enheden er gjort 25 % hurtigere. For eksempelvis søgedisken svarer
X = 1 til almindelig hastighed.
X=1.25 svarer til at søgedisken er 25 % hurtigere. Hældningkoefficienten for de 3
linier kan nu opfattes, som et mål for de partielle afledede. På figuren 6.4.5
ses derfor, at den enhed, hvor den angivne linie har størst hældning er linien
stammende fra CPU-en. Dermed er CPU-en flaskehalsen ved en RC8000 benyttet til
OP-systemet.
$np$
Opsummerende viser figuren, at hvis de i systemet indgående enheder enkeltvis gøres
25 % hurtigere, vil den enhed, der bevirker den største formindskelse i svartiden, være CPU-en.
$ps$$ps$
$nl2$
$ef$
scope user vko2 afs6
finis
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦a61d13389⟧ TextFile

Derivation

TextFile