Livstegn fra Cowi: Skandale-test stadig nede trods optimering

Det lyder utroligt at adaptiviteten (hedder det det?) skulle give så stort et load. Det kunne være spændende at vide noget mere om hvordan testen "adapterer". fx hvor mange spørgsmål der er i alt i en test? Man kan vel ikke lave alt for mange spørgsmål, da man så mister sammenligningsgrundlag når man skal give en karakter, eller hvad?
Er "Adaptionen" på et niveau højere end bare at reagere på om der er svaret forkert/rigtigt?

Jeg vil gentage mit råd til Cowi: start med at læse hele testen ned på brugerens computer og lad den adaptere på klienten. Så kan der umuligt opstå ventetider.

Jeg kom til at tænke på noget andet: Kan man gå tilbage til sine tidligere spørgsmål og svare noget andet, hvis man kommer i tanke om at man har svaret forkert. Det har jeg selv ofte gjort til eksamen, da jeg gik til den slags. Hvis man kan, hvordan påvirker det så den adaptive test?

At de er adaptive betyder, at de indretter sig efter den enkelte elev. Systemet er ikke indrettet efter at give eleverne en karakter, men at undersøge i hvor høj grad de har tilegnet sig undervisningens indhold. (og nej - eleverne kan ikke gå tilbage og rette et forkert svar. Det kan de dog i forbindelse med de digitale prøver)

Det skulle gerne være "umuligt", at to elever oplever samme testgennemgang, for når den ene elev kommer "på dybt vand" serverer systemet nogle lettere opgaver, som eleven bedre kan svare på.

Systemet skulle gerne være et redskab for læreren til at indrette undervisningen efter elevernes individuelle behov. Har lille Peter ikke fattet en meter af ligningsløsning skal der arbejdes med dette mens Mette, som har styr på dette måske skal arbejde lidt mere med arealer og rumfang.

Derefter kan man så tage en længere diskussion om det rimelige i at indrette de digitale tests som man har gjort det. Jeg mener man har skudt sig selv i foden - big time! Denne diskussion handler dog ikke om det tekniske i prøverne men om prøvernes indførelse i det hele taget.

Der var en fin artikel i Weekendavisen i fredags om, hvordan disse tests virker - det dér med adaption, osv. Det var vist en af betingelserne for, at lærerne ville være med i sin tid, da man begyndte at tale om det.

For mig er tests a la disse (ligesom diverse IT-certificeringer) ikke interessante, men på den anden side er niveauet i vort undervisningssystem nu så elendigt (på højde med Angola, som jeg plejer at sige), at man må gøre noget. 15% af de elever der forlader Folkeskolen idag er analfabeter. Nogle steder er 50% af indvandrerdrenge analfabeter, når de går ud af skolen. Ikke godt. Jeg er også til stadighed overrasket over, at skolelærere og journalister ikke kan finde ud af endelser på ord mere. Noget er galt.

Hvis dette "noget skal gøres" indebærer, at man først må dokumentere, at eleverne ikke har lært noget for at have en undskyldning for at skride ind med ordentlig, langvarig og systematisk undervisning i grundfagene, then be it.

Mvh.

Mogens

Nu gætter jeg, men det lyder lidt som at logikken, der styrer det adaptive element, er afkoblet fra resten af testen i bedste SOA stil, d.v.s. med dyre kald imellem hvert spørgsmål. Måske er der en regelmotor eller sådan, der styrer det, måske på en anden maskine, det kan vi jo ikke vide.

Det giver muligvis fin mening fra et arkitektonisk synspunkt, men kræver omhu i belastningtesten.

Det var også min første tanke, at hente hele testen på en gang og lade beregningen foregå på klienten. Der er dog et par problemer. For det første er forudsætningen for beregningen, at klienten skal vide hvilke spørgsmål, der er rigtige og forkerte. Det er dog næppe et praktisk problem, da det ville kræve en betydelig indsats (og betydelige evner) for den enkelte elev at debugge potentielt obfuskeret javascript under prøven for at finde ud af de rigtige svar.

Det andet problem, som jeg ikke var opmærksom på i første omgang, og som er mere betydende er, at hvert testsæt udvælges fra en pulje af 500 opgaver, så derfor skulle hver klient hente rundt regnet 10 gange flere opgaver, end der egentligt bliver brugt. Dette koster en del ressourcer, og man skulle umiddelbart tro, at det ville kræve mindre at foretage den adaptive beregning på serveren (eller et antal servere) i stedet. Det er dog et åbent spørgsmål.

En algoritme, som udvælger en opgave ud fra elevens tidligere valg skal nødvendigvis som input have elevens valg som input, samt evt. adgang til oplysninger om, hvilke opgaver eleven tidligere er blevet stillet, så man undgår gentagelser, så det er næppe helt trivielt. Dog kan beregningen trivielt distribueres, og det er svært at forestille sig, at algoritmen er så tung, at det ville kræve betydelige mængder CPU tid at køre den.

Jeg tror ikke, at man kan komme det nærmere uden yderligere oplysninger fra Cowi, som de indtil videre ikke har ønsket at komme med. At Cowi så er tilbageholdende med oplysninger for et projekt, som ca. koster hver dansker 20 kr, kan man, efter min mening, med god ret kritisere, men jeg har forståelse for, at det i første omgang prioriteres højere at få systemet op at køre igen. Derefter ville jeg dog forvente en større åbenhed fra Cowis side.

For det første er forudsætningen for beregningen, at klienten skal vide hvilke spørgsmål, der er rigtige og forkerte.

Ikke nødvendigvis, der skal bare være logik for at vælge nye opgaver, det behøver ikke nødvendigvis være modelleret som rigtig/forkert. Men måske. Der skulle helt sikkert gøres noget for at undgå snyd.

Det andet problem, som jeg ikke var opmærksom på i første omgang, og som er mere betydende er, at hvert testsæt udvælges fra en pulje af 500 opgaver, så derfor skulle hver klient hente rundt regnet 10 gange flere opgaver, end der egentligt bliver brugt. Dette koster en del ressourcer, og man skulle umiddelbart tro, at det ville kræve mindre at foretage den adaptive beregning på serveren (eller et antal servere) i stedet. Det er dog et åbent spørgsmål.

1) Servermæssigt er det ikke noget problem.
Men hvis testen fylder 2MB og der er 1.000 elever, skal der immervæk hentes 2GB data fra serveren.
Så skal testen "gøres klar" af en lærer i forvejen, eller hentes fra en lokal skole-server. Så skolens internetforbindelse ikke hoster. Jeg er ikke klar over hvad slags forbindelse de danske skoler har, men jeg tvivler på at de allesammen har en 100Mbs linje. Det er helt klart, på papiret, "nemmere" at ligge adaptionen på serveren som Cowi har gjort.

2) Udfra hvad der svares fra Cowi i ovenstående artikel, er det netop den adaptive del der belaster serverne. Derfor må jeg konkludere at hvis "adaptionen" ligges på klienten, løses belastningsproblemet.

Varnish + memcache + web cluster (Linux virtual server) + replikerede databaseservere.

Dynamisk indhold som sjældent ændrer sig kan memcaches.

Varnish serverer de statiske data (og med de rigtige headere også de knapt så dynamiske data).

Det virker også selvom man bruger SSL for så sætter man bare en SSL proxy eller to (virtual server igen) op foran varnish.

Hvordan man kan gå ned på små 15.000 brugere fatter jeg ikke.

Hvorfor i alverden bliver man ved med at ævle om 'samtidige brugere' på et stateless system?

Systemet er netop ikke state-less, hvis det skal tracke brugernes progression gennem testen for at udvælge de næste spørgsmål. Deraf den væsentlig øgede kompleksitet ved, at testen skal være adaptiv.

"1) Servermæssigt er det ikke noget problem.
Men hvis testen fylder 2MB og der er 1.000 elever, skal der immervæk hentes 2GB data fra serveren.
Så skal testen "gøres klar" af en lærer i forvejen, eller hentes fra en lokal skole-server. Så skolens internetforbindelse ikke hoster. Jeg er ikke klar over hvad slags forbindelse de danske skoler har, men jeg tvivler på at de allesammen har en 100Mbs linje. Det er helt klart, på papiret, "nemmere" at ligge adaptionen på serveren som Cowi har gjor"

Det er nu altså ikke så tungt eller svært for serveren at lade brugerne downloade data, hvis man designer systemet korrekt.

Man hehøver jo ikke at bruge den centraliserede model, som alle er så varme fortaler for, da det er det nye buzz word.

Hvis jeg skulle bygge sådan et system, ville jeg havde en lille server på hver skole, da det er maksimalt omkring 500 brugere vi snakker om.

Feks via Web services, kunne man bruge en proxy server, som betyder, at skolerne på gennemsnit kun henter et kopi, per alle deres elever.

Men hvis det er noget der ikke køre som web, kunne man gøre at på dagen (eller dagene) før testen, opsamler hver skole server testen, fra den centrale server - som kan bekræfte at alle har modtaget de relevante data, og programmel. Alle dataerne ligger krypteret på den lille server, indtil der udsendes en decrypt kode fra serveren, og alt data pakkes ud klar til brug - garanti for ingen har set prøven for andre.

Eleverne på hver skole arbejder op mod den lokale server (så er man også ude over internet nedbrud i wan nettet, net overbelastninger osv), og central serveren behøver ikke være overdimensioneret. Lokal serveren cacher, og laver de nødvendige beregninger for whatever adaptive stas man laver.

når testen er færdig, kobler samtlige lokal servere op mod central serverene, og levere ind resultaterne, da det er maskiner der snakker sammen så er svar tider ikke et væsentligt problem, da de ikke har en tidsbegrænsning for at overføre data.

Svartider på sådan et system, burde ikke overstige 1-2 sekunder, da det er et distribueret system hvor hver node kun har et meget begrænset antal brugere, alle data ligger lokalt, på et net man snildt kunne rigge op til at køre gigabit+.

En server med feks 2x quad 2.6GHz CPUer ligger i en 20 000-30 000 dkk klasse. Og levere omkring 50 000 MIPS, så det er nu ikke en vanvittig dyr løsning, at havde distribuerede servere.

Men igen det er spekulation, da man jo ikke kan få lov til at se detailjer.

Det burde da være stateless. Staten burde holdes i klienten eller en front-end.

Det de sansynligvis gør galt, er at gemme "state" i databasen for hvert trin.

I stedet burde de forudgående svar være en del af en query der udvælger den næste opgave.

Der er ca. 2000 skoler i DK. Vil du have 2000 servere til dette ene formål? Og skubbe applikationen ud til alle disse? Og tænde og slukke dem centralt så de ikke står og varmere skolerne op i de 10 måneder, de ikke bruges?

Jeg ville meget hellere en Amazon EC2 løsning klar med et applikationsimage som jeg kunne skrue op for når behovet er der, spørgsmålene i klargjort form på S3, elevernes svar på SimpleDB. Det er rigeligt, og nemt at tilpasse, og der skal bruges meget lidt tid på at lege serverpedel, specielt i forhold til at investere i 2000 servere.

@Micahel: mener du virklig det her?

Det burde da være stateless. Staten burde holdes i klienten eller en front-end. Det de sansynligvis gør galt, er at gemme "state" i databasen for hvert trin.

Jeg skal ige forstå dig korrekt, du vil bygge det hele op via client side state?

I stedet burde de forudgående svar være en del af en query der udvælger den næste opgave.

Jeg skal lige forstå, hvordan kan de forudgående svar være en del af en query, hvis ikke de er gemt i basen? Det er måske en query mod noget andet?

Jeg forstår ikke at det kan være så udbredt herinde at mene at state hører til ude på klienten. Jeg har meget svært ved at se behovet herfor og hvad hvis browseren går ned, brugeren rammer ctrl+w eller kommer til at lukke den ved en fejl, maskinen genstarter etc? Hvad med alle de forskellige javascripts-engines, som konstant udvikles, opdateres og optimeres - kan vi garantere at der ikke er klienter der kommer i problemer? Hvor nemt er det at pille ved dataene når så meget ansvar placeres ude på klienterne?

Umiddelbart vil jeg mene at det nemmeste er at holde klienterne så tynde som mulige for at undgå problemer. Vi har som udviklere fuld kontrol over server-side miljøet, det er meget lettere at garantere stabil drift her (medmindrer man hedder COWI altså :p). Desuden er der jo ikke tale om shared-state, hver bruger skal bare have sin egen state - det er jo piece-of-cake. Det eneste der er shared-data er formentlig det her adaptive test-system, men det er trodsalt et ret afgrænset subsystem, så det burde ikke give de helt store problemer hvis man har prøvet at skrive samtidigheds-kode før.

Jeg er blot glad for at det ikke er Michael Nielsen der er chefarkitekt på det her projekt :-)
Sorry, men det er godt nok et overkompliceret løsningsforslag du er ude i der ;-)

@Michael Nielsen

En server med feks 2x quad 2.6GHz CPUer ligger i en 20 000-30 000 dkk klasse. Og levere omkring 50 000 MIPS, så det er nu ikke en vanvittig dyr løsning, at havde distribuerede servere.

Hvor i alverden har du de tal fra?
Regnereglen jeg er stødt på hos moderniseringsfolk er at 1xquad core xeon topmodel svarer til 800 til 1.000 MIPS. Nogle siger endda mindre.

Jeg skal ige forstå dig korrekt, du vil bygge det hele op via client side state?

Ja, hvorfor ikke. Svarene skal selvfølgelig løbende sendes til en log i systemet ( eller kun lokalt på skolen). Herved kan snyd afsløres og opgaven kan efterfølgende evalueres baseret herpå. Skulle state gå tabt på klienten, kan den eventuelt reddes fra denne log. Det burde dog sjældent ske.

Jeg skal lige forstå, hvordan kan de forudgående svar være en del af en query, hvis ikke de er gemt i basen? Det er måske en query mod noget andet?

Nej, det forestiller jeg mig ikke. Det kan vel lade sig gøre at holde svarene i et komprimeret/krypteret format i klienten og medsende forløbet ved hver forespørgsel.

Hvor lang tid sidder hver elev og tygger på et spørgsmål - vel næppe under et minut?

Det giver altså gennemsnitligt 250 request per sekund.

Håndtering af 250 Ajax request som gennemsnit per sekund er altså ingenting.

Og hvor meget data overføres så per request - 500 bytes er faktisk ret meget, så hvis det sættes som snit taler vi om stort set intet load.

Så hvad er det lige der går galt - jeg kunne forstå hvis vi talte om 15 millioner samtidige brugere, men 15 tusinde?

/Christian

Jeg forstår ikke at det kan være så udbredt herinde at mene at state hører til ude på klienten.

Den må jeg nok tage på min kappe, men jeg har generelt en mission med tykke klienter og deres mange fordele :-)

Jeg har meget svært ved at se behovet herfor

Det kom sig oprindeligt af at der var lange svartider når brugeren skulle hoppe til næste spørgsmål, med en tyk klient kan du elliminere dette. Jeg har gjort det i praksis på mit fritids projekt http://obsurvey.com hvor et spørgeskema på flere sider hentes ned på første side, og det at hoppe til næste side gøres uden der skal hentes noget fra serveren.

og hvad hvis browseren går ned, brugeren rammer ctrl+w eller kommer til at lukke den ved en fejl, maskinen genstarter etc?

Du gemmer svarene ved hvert sideskift (asynkront, så man ikke venter på serversvar, med fx XHR)
Da brugeren er logget ind laver man det sådan at de kan fortsætte fra hvor de slap.

Hvad med alle de forskellige javascripts-engines, som konstant udvikles, opdateres og optimeres - kan vi garantere at der ikke er klienter der kommer i problemer?

Nu er garantier svære at udstede, men hvis du holder dig til W3C standarderne er det i praksis ikke det store problem. Du kan jo sige det samme om at bruge HTML, hvordan ved du at browserne renderer HTML korrekt?

Hvor nemt er det at pille ved dataene når så meget ansvar placeres ude på klienterne?

Tja, det er vidst allerede nemt at pille ved data i Cowi's system (http://www.computerworld.dk/art/51518)
Det centrale er at man ikke kan se hvilke svar der er rigtige/forkerte og at svardata valideres på serveren.
Noget helt andet er at det er svært at se hvad en elevs motivation skulle være for at snyde, når nu testen ikke udmynter sig i en karakter, men skal bruges til at sikre at eleven får den korrekte undervisning?

Ja, hvorfor ikke. Svarene skal selvfølgelig løbende sendes til et centralt sted. Herved kan snyd afsløres. Skulle state gå tabt på klienten kan den eventuelt reddes fra denne log. Det burde dog sjældent ske.

Så altså ikke stateless som du sagde før, blot med state i klienten i stedet for på serveren - men dog stateful.
Og med den undtagelse at svarene bliver sendt (tilstand overføres) til serveren fra klienten?

Jeg kan altså ikke se det store problem i server side state her, det kan sagtens skalere fint.

Det du beskriver lyder som en server side state model, med en cache på klienten.

Server side state er normalt "et stykke af kage", og hvis leverandøren ikke kan finde ud af det, skal han nok ikke bevæge sig ud i client side state.

Så altså ikke stateless som du sagde før, blot med state i klienten i stedet for på serveren - men dog stateful.

Jo - stateless - på server side. Svarene sendes et andet sted hen, helt asynkront. Ingen updates i databasen, ingen locking, ingen ventetid.

Server side state er normalt "et stykke af kage", og hvis leverandøren ikke kan finde ud af det, skal han nok ikke bevæge sig ud i client side state.

Det har du helt ret i. Glem alt hvad jeg skrev.

Jo - stateless - på server side. Svarene sendes et andet sted hen, helt asynkront. Ingen updates i databasen, ingen locking, ingen ventetid.

Ja men hvor er det andet sted de sendes hen - asynkront?

@Bo Jensen

Det de sansynligvis gør galt, er at gemme "state" i databasen for hvert trin.

Det er nu ikke det jeg vil gætte på, 15.000 elever x 50 opgaver pr styk = 75.000 databaseopdateringer over testens varighed (1 time?) Det burde ikke volde nogle problemer.
Cowi prøver at skyde skylden på at det er fordi testen er adaptiv, og det er helt nyt. Man kunne frygte det er et røgslør for at skjule over inkompetence.

Hvis jeg skulle gætte vil jeg gætte på at der ligger nogle O(n^2) algoritmer i systemet.

Ja men hvor er det andet sted de sendes hen - asynkront?

Det kan sagtens være en tabel i databasen. Via en buffer/cache. Hovedsagen er at det foregår asynkront. Regelmaskinen kaldes i forbindelse med en query. Parametrene indeholder historik. Her er alt hvad regelmaskinen behøver at vide for at vælge næste opgave. Data fra føromtalte tabel skal først bruges ved testens afslutning.

I tabellen ligger således en kopi alle parametrene til queries under hele forløbet. Er der snydt vil man finde inkonsistens i forløbet.

Det er nu ikke det jeg vil gætte på, 15.000 elever x 50 opgaver pr styk = 75.000 databaseopdateringer over testens varighed (1 time?) Det burde ikke volde nogle problemer.

Jeg tror (min database viden er ikke af nyere dato) at updates af ovennævnte omfang til en tabel med mange indexes og mange tilknytninger til andre tabeller godt kan få en database i knæ.

Cowi prøver at skyde skylden på at det er fordi testen er adaptiv, og det er helt nyt. Man kunne frygte det er et røgslør for at skjule over inkompetence.

Måske har du ret. Jeg kan ikke se, hvordan denne kompleksitet kan have så stor betydning for systemets svartid.

Prisen er memory, hvor 'state' opbevares, men da memory er en statisk størrelse, giver det stadig ingen mening af tale om 'samtidige' brugere, kun samtidige requests.

Hvad med data (session-state) der opdateres/hentes fra samme table på serveren med fx page-level-locking. Så bliver samtidige brugere pludselig meget interresant. Og det er bare eet eksempel.

Selv om jeg giver dig ret i at HTTP er stateless, mener jeg stadig det giver mening at tale om samtidige brugere. Da det kan have stor inflydelse på skaleringen, at der er session-state mellem requests for disse brugere på serveren.

Jeg tror (min database viden er ikke af nyere dato) at updates af ovennævnte omfang til en tabel med mange indexes og mange tilknytninger til andre tabeller godt kan få en database i knæ.

Hvis den kan det så bør man enten overveje sit database-design eller også ville jeg nok overveje at skifte database-producent. 75.000 inserts er ingenting, det burde problemfrit kunne håndteres indenfor 1 minut på en bare nogenlunde moderne database-server.

Allan:

Da det kan have stor inflydelse på skaleringen, at der er session-state mellem requests for disse brugere på serveren.

Det gode ved det her scenarie er jo at den data der skal gemmes i sessionen kun skal tilgåes af selvsamme bruger - det giver et optimalt skaleringsscenarie. Derfor er der intet som helst problem i at håndtere staten serverside og jeg ville blive meget overrasket hvis COWI skulle have et problem i den forbindelse.

Jeg vil ikke afvise at tykke klienter kan have fordele i visse tilfælde, men det her ser jeg bare ikke som værende et af dem og jeg mener det vil være at overkomplicere en ellers simpel opgave at begynde at lægge så meget forretnings-forståelse ud i javascript.

Det gode ved det her scenarie er jo at den data der skal gemmes i sessionen kun skal tilgåes af selvsamme bruger - det giver et optimalt skaleringsscenarie. Derfor er der intet som helst problem i at håndtere staten serverside og jeg ville blive meget overrasket hvis COWI skulle have et problem i den forbindelse.

Det har du ret i. Det Cowi prøver at skylde skylden på er at testen er adaptiv. Det kan man i sig selv undre sig over. Men med en præmis der hedder at det er sindsygt tungt at beregne hvilket spørgsmål der skal vises som det næste, giver det god mening at distribuere dett load, ved at lægge beregningen på klienten. Men igen, der er en risiko for at vi ekstrapolerer fra et Cowi røgslør.

Så hvad er det lige der går galt - jeg kunne forstå hvis vi talte om 15 millioner samtidige brugere, men 15 tusinde?

Ifølge http://evaluering.uvm.dk/BinaryContentProvider?binaryId=2871 er der tale om, at systemet skal kunne klare 6000 samtidige brugere.

@alan ebdrup

Hvor i alverden har du de tal fra? Regnereglen jeg er stødt på hos moderniseringsfolk er at 1xquad core xeon topmodel svarer til 800 til 1.000 MIPS. Nogle siger endda mindre.

Det skal noteres at MIPS er et vidt begreb, en som er dhrystones, og whetstones - en link fra nettet.

http://www.notebookcheck.net/Intel-Core-2-Quad-Q9000-Notebook-Processor....

Intel Core 2 Quad@2GHz

SiSoft Sandra Dhrystone (MIPS):
min: 36460, avg: 36780, max: 37068 MIPS
SiSoft Sandra Whetstone (MFLOPS):
min: 25492, avg: 26966, max: 29405 MFLOPS

2x36780 ca 72000 MIPS.

Dog er det en notebook test.

Men MIPS er et vidt begreb.

Men allerede i midt 1990'erne kunne man opnå 1000 mips på en computer, men i specifikke test.

Tommelfinger reglen er at der på ikke pipline processor går mellem 2-30 (nogle kan nå op på 128) cykler af klokken per instruktion, altså en 2GHz processor som er 2000 MHz, ville uden piplining, eller coprocessor udføre mellem 1000 - 100 Mips alene. Med superscalar pipelining, og andre tricks, er der som regl 4-16 instruktioner i gang per pipeline, mens co-processoren (integer, og floating point units køre sideløbene).

Nogen afregner mips med et gennemsnit af alle instruktioner, og får et langt lavere tal. Dette er grunden til at man standardiserede med Dhrystones og Wethstones som en beregnings metode.

Feks hvis man udføre hvisse instruktioner som rydder piplines ofte, og kombinere med de store instruktioner, så kan man sagtens presse processorene ned til et par 1000 instruktioner.

MIPS fik et øge navn sidste i 80'erne.

MIPS = Meaningless Indication of Performance

Det har kun en relevance hvis man bruge den samme test på den samme type processor. Man kan ikke sammenligne processorer, da funktions måden affektere antallet af instruktioner der skal til for at lave en opgave, feks CISC processorer laver mange ting i en instruktion, mens RISC processorer lave få ting, men fyre instruktioner af hurtigt.

Mange processorer er nu hybrid, hverken eller, og både og RISC og CISC.

@Nikolaj

@Micahel: mener du virklig det her?

Hvis du refere til min divide and conqur, ja, det er en effektiv måde at løse et problem på hvis man har transport veje problemer.

Ved at distribuere opbevaring nodes, og beregnings nodes, over kommer man mange problemer.

Skyen (Centraliseret server) som er så populær forudsætter at der er masser af processor kraft - det er nemt at lave - men forudsætter også at netværks forbindelserne er store, og stabile, jeg tvivler mange skoler har ret meget i båndbredde. Så når man snakker multimedia at det er ganske fornuftig at sprede transport belastningerne ud, mens man samtidigt overkommer problemet med at nogen ikke kan tage eksamen, fordi en eller anden firewall, eller internet segment ikke kan klare belastningen.

Desuden er det hunde dyrt at få en firewall der kan klare mere end et par 100 Mbit i throughput.

Desværre ser det ud til at det er grafik kort MIPSne jeg citere her.

@Michael Nielsen

Det skal noteres at MIPS er et vidt begreb

Ja, det er nok det der er problemet. Jeg troede du snakkede om mainframe MIPS, dem man betaler for på mainframe.

Der er stadig ikke tale om 'samtidige' brugere, men requests. Lad os lave et primitivt system, der kun består af dig og mig, og uden 'timeouts'. Jeg logger ind mandag morgen kl 8:00, og udtager en 'session' gemt i (memory/filer/database.. whatever). Nu er jeg 'online', men laver ikke en skid. Dagen efter logger du på, og udtager din 'session'. Du laver heller ikke noget, men nu er vi to 'samtidige' brugere. Gang disse to brugere op med 10.000, men det ændrer ikke ved, at hvis disse 20.000 brugere ikke laver noget, så belaster det ikke ('session')systemet.

Det er rigtigt at en del af beregningen for hvad load der er på systemet er antallet af requests en bruger laver. Men hvis præmissen er hvorvidt det giver mening at tale om samtidige brugere, eller om det kun giver mening at tale om requests vil jeg mene at det kan koges ned til spørgsmålet:
"Er der forskel på en request, for en bruger der er logget ind, eller en bruger der ikker er?"

I de fleste systemer er der meget stor forskel på at være logget ind og ikke være det. Der er simpelthen tale om en helt anden type requests, en bruger laver når han/hun er logget ind.

Derfor det giver mening at tale om samtidige brugere, men for at sige noget meningsfyldt om hvad load, de samtidige brugere giver på systemet, skal man kende det typiske brugsmønster, som fx kunne måles i requests pr tidsenhed.
Men i og med det er afgørende for disse requests' load på systemet, at brugeren der laver dem, er logget ind. Giver det mest mening at tale om samtidige brugere, kontra samtidige requests. Selvfølgelig under forudsætning af at modtageren har en idé om hvad det typiske brugsmønster er for en bruger. Hvad jeg mener man må have i dette tilfælde.

Pyha. Nå, men jeg mener ikke du kan afskrive at det giver mening, at tale om samtidige brugere.

Antallet af brugere, der er logget ind, eller bare har en "session" samtidig kan afspejles i det hukommelsesforbrug, de bruger på den pågældende applikationsserver (afhængig af løsningen). Ellers betyder "logget ind" ikke noget i sig selv, ud over at der typisk er en korrelation imellem brugerens "tilstand" i forhold til et system og de load, de smider på det.

Nogle teknologier har præference for at smide sessionoplysninger nedad til DB'en ("shared nothing", skaleringen skal ske i DB laget), andre teknologier lægger op til at holde en masse gods i sessionobjekter, og kan f.eks. finde ud af at replikere sessions imellem maskiner i et cluster (skalering sker delvist i appserverlaget).

I begge tilfælde kan man risikere at dumme sig gevaldigt hvis man ikke tænker sig om når løsningen skal skalere, eller hvis man ikke load-tester.

Og endelig kan man blive fanget af helt banale fejl som kan være nok så bøvlede af finde, f.eks. en databaseserver der misser et index fordi JDBC driveren sender en strengparameter som UCS-2 tegn i stedet for 8-bit. Eller en disk i et array er gået kold og ingen ser advarslerne. Eller en appserver der har et uskyldigt flag sat og pludselig stjæler alle DB connections. Eller nogen har sat virusscanneren til at scanne databasen tablespaces - eller noget andet sært.

Så i den sidste ende kommer det an på udvikleres, testeres og driftfolks kompetencer og ikke mindst de forventninger, der stilles til systemets belastning.

Jeg ville anbefale en REST-løsning. Hver spørgsmål til hver elev skulle have en unik url (eks. http://skoletest.dk/elev/123/test/1/spm/3). Et GET til url'en skulle give spørgsmålet(og evt. besvarelsen hvis spørgsmålet er udfyldt). Besvarelsen skulle sendes vha. et PUT. Navigation kunne ske ved hjælp af links til disse url'er. Den samlede løsning skulle have sin egen url (eks. http://skoletest.dk/elev/123/test/1)

En simpel løsning der burde kunne scalere [til et par millioner brugere ;-)]

Det hedder tilstand på dansk. Jeg ved godt dansk er svært, men efter 5 mennesker ævlede om 'states' var det ligesom nødvendigt at pointere.

Jeg skal love at kalde det en ReTO-løsning næste gang ;-)

Men hvordan er det du mener det har nogen som helst indflydelse på skalering i dette tilfælde?

Man kan som Jesper skriver vælger nok så mange fine blue prints, teknologier og frameworks osv. dog er de ikke bedre end de hænder de kommer i.

En simpel løsning der burde kunne scalere [til et par millioner brugere ;-)]

Jeg tror det vigtige her er kompetencesættet hos leverandøren mere end det er om løsningen er en ReST løsning eller ikke som afgør skalerbarheden. Ikke-ReST løsning skalerer ligeså fint som ReST løsninger.

Hvilket usage pattern baserer du et par mio. brugere på? Og hvilken størrelse kværn havde du tænkt dig skal kre den?

Hvis du refere til min divide and conqur, ja, det er en effektiv måde at løse et problem på hvis man har transport veje problemer.

Men har de da det - transport veje problemer?

Ved at distribuere opbevaring nodes, og beregnings nodes, over kommer man mange problemer.

Men du skaber jo også en hel del i dit setup, se bare på dem som Jesper outliner.

Skyen (Centraliseret server) som er så populær forudsætter at der er masser af processor kraft - det er nemt at lave - men forudsætter også at netværks forbindelserne er store, og stabile, jeg tvivler mange skoler har ret meget i båndbredde.

Hvad er ret meget? Tror du ikke de har nok til en gang HTML/Flash eksamen, det tror jeg, ellers er det nok bedre at investere pengene her, end i dyrt hardware som de kan smide ud om nogle år, da det er forældet. Jeg tror i øvrigt ikke på er et problem, på mange skoler sidder eleverne allerede og ser Youtube og Flash, uden problemer, hvorfor skulle de ikke kunne det til en eksamen.

Desuden er det hunde dyrt at få en firewall der kan klare mere end et par 100 Mbit i throughput.

Sagde du ikke at du betvivlede at skolen havde høj båndbredde, og nu snakker vi 100Mbit? Nå men hvis du vil have et tip til en firewall som kan, er IP-filter gratis og den kan.

@Nikolaj

For det første kan selv erfarne og dygtige udviklere komme galt afsted hvis de ikke bekender sig til en arkitekturstil - ReST eller ej. Arkitekturstil er vigtig!

For det andet er der en god empiri der siger at ReST giver gode skaleringsevner.

For det tredie er der masser af god HTTP-software der kan hjælpe.

Millioner af brugere kræver nok en del hardware, men 15.000 kan serviceres af min laptop.

For det første kan selv erfarne og dygtige udviklere komme galt afsted hvis de ikke bekender sig til en arkitekturstil - ReST eller ej. Arkitekturstil er vigtig![quote]Absolut er arkitekturstil vigtigt, men om man kommer galt afsted, dygtig/erfaren eller ikke, er afkoblet fra arkitekturstil. [quote]For det andet er der en god empiri der siger at ReST giver gode skaleringsevner.

Ja det er der, men man kan godt skalere fint uden at benytte ReST som arkitekturstil.

For det tredie er der masser af god HTTP-software der kan hjælpe.

Det er der, men det er der også for ikke ReST løsninger, så det er ikke rigtig et argument.

Millioner af brugere kræver nok en del hardware, men 15.000 kan serviceres af min laptop.

Enig! (på min gamle laptop).

Antallet af brugere, der er logget ind, eller bare har en "session" samtidig kan afspejles i det hukommelsesforbrug, de bruger på den pågældende applikationsserver (afhængig af løsningen). Ellers betyder "logget ind" ikke noget i sig selv, ud over at der typisk er en korrelation imellem brugerens "tilstand" i forhold til et system og de load, de smider på det.

Det er netop denne korrelation der gør det interresant.
Brugere + brugsmønster. Det er det der er den interessante vinkel på en applikation, set med en forretnings øjne. Det vigtige er hvor mange samtidige brugere vi kan servicere, ikke hvor mange requests vi kan levere. Det hele afhænger af øjnene der ser. Samtidige brugere er og bliver en vigtig størrelse, at den så er lidt mere fluffy end requests/sekund det må vi se ud over.

Det der er vigtigt er at teste belastning:

Antal samtidige brugere (logget ind)
Antal aktive brugere (og "think time" imellem handlinger).

Så f.eks. er et testscenarie 1.000 samtidige brugere, 200 af dem aktive med think time 15 sekunder.

Det er også kendt at det er ligemeget med gennemsnitsudregninger, for det er derfor alle disse folketinget.dk skat.dk osv går ned. Det handler om at kunne håndtere spidsbelastningerne. Det er her Skyen er glimrende fordi den ikke bruger benzin i tomgang, men har rigtig mange hestekræfter når det gælder.

(med forbehold for applikationstyper som selvfølgelig skal stå og konstant behandle X requests/sekund).

Jeg tror (min database viden er ikke af nyere dato) at updates af ovennævnte omfang til en tabel med mange indexes og mange tilknytninger til andre tabeller godt kan få en database i knæ.

Jeg laver nogen indlæsningsrutiner, som i praksis laver insert for hver post, i indexerede tabeller.

MySQL og en bovlam IBM X100 server.

Kan snildt håndtere 75.000 inserts på under et minut.

/Christian

Samtidige brugere er og bliver en vigtig størrelse, at den så er lidt mere fluffy end requests/sekund det må vi se ud over.

Jeg er ikke enig, da jeg ikke mener det er relevant at tale om samtidige brugere i forbindelse med HTML.

I og med, som andre også har pointeret, at HTML er stateless, så skal der holdes styr på brugerene på andet sæt - og det kan så gøres ved at brugernøgle overføres ved hver transaktion, hvorved det er request/sekund der er interessant.

Og som jeg tidligere skrev, så tror jeg at 250 (som er peanuts) request/sekund er endda meget højt sat.

/Christian

Inserts er ikke updates. Indexes og foreign keys kan gøre en væsentlig forskel.

Ellers ja, det kan være jeg skal revidere min opfattelse af hvad databaser kan.

Det vigtige er hvor mange samtidige brugere vi kan servicere, ikke hvor mange requests vi kan levere

Det bør være nærmest ligegyldig hvor mange brugere der er logget på systemet (det er bare en cookie der skal resolves). Det vigtige bør være antallet af requests. Ellers har man et alvorligt designproblem.

Og som jeg tidligere skrev, så tror jeg at 250 (som er peanuts) request/sekund er endda meget højt sat.

Men, men, men... requests/sekund er en mere løs metrik end pølser/gris eller målchancer/halvleg :-)

250 requests efter favicon.ico er ikke meget, men måske er 250 requests efter afleverSvarOgBeregnHvilketSpørgsmålDerSkalStillesNu er måske i overkanten. Og så er vi tilbage ved at belastningsprofilen per bruger er af afgørende betydning. Og i dette tilfælde er det ennda meget meget nemt at estimere.

Reelt er der ingen grund til at vi sidder og diskuterer tynde vs tykke klienter, vilde hardware-opsætninger, REST-løsninger, javascript fixfaxerier osv.

For det grundlæggende system er så simpelt at man nærmest skal gøre sig umage for at indføre en flaskehals når vi kun snakker 6000 samtidige brugere.

Det eneste de har og som de også undskylder sig med, er deres adaptive test-system, som er den reelt største ubekendte. Uden at vide hvilke krav de har haft hertil og hvordan de har valgt at implementere deres løsning, kan vi ikke rigtig sige noget herom.

Det ved de selvfølgelig også godt og derfor lugter det, som en nævner tidligere, lidt af at de bruger det som røgslør - men når det er sagt, så virker det dog sandsynligt at det er her de har klokket i det, da det formentlig er eneste sted man kunne forestille sig at de har noget shared-data tilgang og at resten af setup'et burde være lige ud af landevejen når der er tale om så få brugere.

Prøv eksempelvis at lave et index, der dækker flere felter, hvoraf et af dem, f.eks "opgave_nummer" skal opdateres. Lav så en mængde updates på opgave_nummer.

.. nej jeg forestiller mig ikke, at det er det de har gjort.

Der skal nok mere til.

@Jesper

Lad os prøve at kigge på

afleverSvarOgBeregnHvilketSpørgsmålDerSkalStillesNu

afleverSvar - OK

BeregnHvilketSpørgsmålDerSkalStillesNu - I ReST er svaret gemt i hypermedia betingelsen - I praksis er det links i HTML'en

BeregnHvilketSpørgsmålDerSkalStillesNu - I ReST er svaret gemt i hypermedia betingelsen - I praksis er det links i HTML'en

Ah, er det er ikke lidt for rosenrødt. Vi kan ikke lade klienten se sammenhængen imellem hvilket svar han/hun vælger, og hvilken URL han/hun havner på, ellers er det jo ikke adaptivt.

I min bog vælger prøvelogikken det næste spørgsmål ud fra de point, der er scoret indtil videre, og viden om hvilke spørgmål, der ikke er stillet.
Om det nye spørgsmål så transporteres i en HTML formular returneret fra samme POST eller en POST med omdirigering til en ny formular, det er lidt hip som hap.
(og, nej, det er ikke raketvidenskab, men det er dog tilstand gemt på serversiden, og noget tungere end favicon.ico)

@Jesper

Jeg håber sørme ikke at stillede spørgsmål afhænger af tidligere svar - hvad sker der så hvis du går tilbage og laver en besvarelse om - bliver en del af din samlede besvarelse så ugyldig/irrelevant?

.. men hvorfor gemme en tilstand på server side, hvis den kan udregnes på ingen tid udfra en streng, der nok kan fylde mindre end 1480 bytes.

@Daniel:

Reelt er der ingen grund til at vi sidder og diskuterer tynde vs tykke klienter, vilde hardware-opsætninger, REST-løsninger, javascript fixfaxerier osv.

Helt enig, overhovedet ingen - det er rent "Min kæphest er større end din" (og dog alligevel en skæg fritidsbeskæftigelse). Det næste bliver en langspytningskonkurrence i at lave et plagiat af de nationale tests som kan skalere til 10000 elever, der skal kunne tage testen inden for 10 minutter på den eleganteste måde. (ja, jeg ved godt det ikke hedder 'eleganteske') Nej vent, TO langspytningskonkurrencer, den anden om hvem der laver den enkleste, realistiske belastningstest.

For det grundlæggende system er så simpelt at man nærmest skal gøre sig umage for at indføre en flaskehals når vi kun snakker 6000 samtidige brugere.

Ikke helt enig. HVIS man har prøvet noget tilsvarende før, og HVIS man er bevidst om hvilken udfordring man er i gang med, så skal man ikke gøre sig meget umage for at undgå en sådan flaskehals.

Og når det så er sagt håber jeg at der er nogen derude, der har gavn af debattens afvejninger, for det er jo trods alt et fåtal af webudviklere, der jævnligt har så mange brugere at belastning p.g.a. brugerantallet er en udfordring. Hvis ikke så må jeg heller komme tilbage til noget, der giver mere mening f.eks. http://www.eclipse.org/webtools/sse/

@Kim:
Spørgsmålene afhænger af de svar du har givet, svarer du rigtigt får du sværere spørgsmål. Og du kan ikke gå tilbage.

@Bo:
Du er nødt til at gemme tilstanden for brugerens vej igennem systemet på en måde som brugeren ikke selv kan manipulere. Jo, du kan godt gemme det hele i en cookie eller et skjult felt, hvis du krypterer det med en nøgle som kun serveren kender, men så skal du pludselig til at tænke på replay attacks og så videre.

@Kim

BeregnHvilketSpørgsmålDerSkalStillesNu - I ReST er svaret gemt i hypermedia betingelsen - I praksis er det links i HTML'en

Er det adaption motoren (dem som Cowi skyder skylden på) som udvælger næste spørgsmål? Så kan du altså ikke realisere din ReST løsning således. Det er vel ideen med at løsningen er adaptiv.

@Christian Nobel

Jeg er ikke enig, da jeg ikke mener det er relevant at tale om samtidige brugere i forbindelse med HTML.

Så må vi vere enige om at være uenige.

I og med, som andre også har pointeret, at HTML er stateless, så skal der holdes styr på brugerene på andet sæt - og det kan så gøres ved at brugernøgle overføres ved hver transaktion, hvorved det er request/sekund der er interessant.

Hvorfor er det vigtigt at der holdes styr på brugerne på andet sæt? Det vigtige er vel at der holdes styr på brugerene? Og interessant på hvilken måde? For hvem?

Hvis brugere der er logget ind laver tunge beregninger de betaler for og dem der ikke er logget ind ikke gør og ikke betaler. Så tror jeg du hurtigt vil komme til at stå til regnskab for hvor mange samtidige brugere dit system kan klare og ikke hvor mange requests/sekund det kan klare.

På samme måde, uanset om Cowi har designet deres system med 100 Ajax-kald pr sidevisning eller et enkelt kald per sidevisning, så kommer de til at stå til regnskab for hvor mange samtidige brugere der kan være på systemet. Så tror jeg at kunden er ret liggelad med at de kan fremvise imponerende tal for hvor mange requests de klarer pr. sekund.

@ Jesper & Nikolay

Hvis dette er rigtigt, så har man langt større problemer end IT-performans ved disse tests. Der vil komme en statistisk usikkerhed der vil gøre besvarelserne fuldstændig irrelevante. Måske skulle man finde en statistiker der kunne kigge på problemet.

Hvordan vægter man de enkelte besvarelser?

Teknisk kan jeg ikke følge med i denne diskussion, men jeg kan se at mange totalt misforstår hvordan de her test virker/afvikles.

Et par eksempler

Jeg håber sørme ikke at stillede spørgsmål afhænger af tidligere svar - hvad sker der så hvis du går tilbage og laver en besvarelse om - bliver en del af din samlede besvarelse så ugyldig/irrelevant?

Jo, det gør det. Det er hele ideen i at tetene er adaptive.
Eleverne kan IKKE gå tilbage og ændre en svar. Svarer de rigtigt får de et svære spørgsmål, forkert et lettere - dog testet der i hver test flere såkaldte "profilområder", og det er ikke givet at det næste spørgsmål ligger i samme profilområde som det der netop er er svaret på, og der kan derfor gå et par spørgsmål inden man oplever at niveauet tilpasser sig.

Hvor lang tid sidder hver elev og tygger på et spørgsmål - vel næppe under et minut?

Det er MEGET forskelligt - både fra spørgsmål til spørgsmål og fra elev til elev. Nogle elever kan svare på nogle spørgsmål på under 5 sekunder, mens andre måske tager 2 minutter. Men det jeg har set ved efterhånden en del test er "tygge-tider" væsentligt under et minut. Lærerne blvier bedt om at opfordre eleverne til ikke at bruge alt for lang tid på hvert spørgsmål - har de ikke et bud skal de gå videre. Det er svært for mange elever, da vi i andre sammenhænge i skolen opdrager dem til at være nysgerrige, og undersøge tingene grundigt...

Jeg har ikke kigget på demoerne, men man kan vel regne det ud fra antal spørgsmål pr. estimeret time ? (Sidst jeg var til eksamen i f.eks. matematik, var der 5 opgaver til 4 timer)

Prøv at kigge på demoerne, og du vil bliver overrasket.
Det har intet med en eksamen med 5 opgaver til 4 timer at gøre. Uden at lyder sur så en opfordring til at prøve at sætte dig ind i hvad det handler om. Gad vide om mange it-fejl ikke sker fordi de ellers dygtige teknikkere ikke har sat sig ordentligt ind i hvordan kunderne skal bruge systemerne...

Det er klart, at hvis man siger alle tests (på tværs af fag) stater i morgen kl. 8:00, så sidder alle da parat til at hakke på tastaturet når klokken slår 8:00. Selvfølgelig skal samme fag afholdes samme dag (for at undgå snyd), men der er vel ikke nogen naturlov, der forhindrer at områda A starter 8:00, område B 8:10 osv,

Nej, det er HELT forkert. Det er ikke en eksamen, men en test der kan tages når klassen/læreren vil indenfor en lang periode. De samme spørgsmål genbruges gennem flere år.
Ovenstående vidner om at man tror testene er ens for alle elever og nemt kunne være hentet ned til den enkelte klient - sådan er det ikke. Der er en pæn stor opgavebank til hver test som der trækkes opgaver fra.
Så nej, test starter ikke på samme tidspunkt.

Det var lige et par kommentarer fra en af de lærere (og it-vejleder) der står ude i folkeskole-virkeligheden og arbejder med det "på gulvet" - et ellers fantastisk arbejde, hvis bare vi kunne blive fri for alle de bedrevidende folk der ikke har sat sig ordentligt ind i det de taler om (og så skal konsulenter der faktisk har læst på deres lektie være så hjertlige velkomne til at komme og inspirere os, så vi kan udvikle os for det er der brug for - men alle dem der ikke har gjort deres hjemmearbejde: hold jer venligst væk)

@Kim: Her tror jeg netop at statistikerne har været inde over, jeg vil ikke gøre mig klog på statistik, det ligger 15 år tilbage og det var morgenlektioner!

Mit gæt er at man vægter de enkelte svar med en vægt svarende til sværhedsgraden, således at man ikke får lige mange procent korrekt hvis man svarer 9 spm rigtigt og det sidste forkert, som hvis man svarer 9 forkert og ét rigtigt.

Men mon ikke der er svar hér:
http://en.wikipedia.org/wiki/Computerized_adaptive_testing

@Jesper
Enig sjov fritidsbeskæftigelse til ingen verdens nytte :-)

Jeg forestiller mig at klienten sender en streng som indeholder en liste over gennemførte opgaver samt svaret på aktuel opgave, ved hver svaraflevering ( simplificeret ).

På server sendes denne streng videre til en log - (buffer -> tabel ). Strengen fungerer også som input til "regelmaskinen" som beregner næste opgave ( on the fly ).

Regelmaskinen skal ikke tage stilling til noget der først skal indsættes/lagres. Transaktionen er derfor kun afhængig af noget, der kan udtrykkes i request/sekund.

Det der logges, havner sidenhen i en tabel. Denne tabel bliver benyttet til at bestemme resultat samt om der er snydt. Der kan i princippet kun snydes ved at manipulere med hvilke opgaver der tidligere er gennemført. Men det vil være nemt at afsløre via loggen.

Til en skriftlig eksamen kan man da godt gå en tur rundt i lokalet og se hvad de andre skriver - der er jo ikke bure eller lænker. Jeg tvivler dog på at man består eksamen på den måde.

Det var lige et par kommentarer fra en af de lærere (og it-vejleder) der står ude i folkeskole-virkeligheden og arbejder med det "på gulvet" - et ellers fantastisk arbejde, hvis bare vi kunne blive fri for alle de bedrevidende folk der ikke har sat sig ordentligt ind i det de taler om (og så skal konsulenter der faktisk har læst på deres lektie være så hjertlige velkomne til at komme og inspirere os, så vi kan udvikle os for det er der brug for - men alle dem der ikke har gjort deres hjemmearbejde: hold jer venligst væk)

Godt ord igen, de gode it løsninger opstår jo først når IT folkene har lært nok af domænet til at forslå de rigtige løsninger, og når brugere/ejer forstår nok at it til at se mulighederne (og begrænsningerne) deri.

Tak for afklaringen!

@Jesper

Jeg havde sjovt nok også statistik fra 8 til 10 de første 2 år - senere blev det 14 til 16 og så gik det meget bedre ;-)

Prøv lige at se på denne her betingelse

all items must be pretested with a large enough sample to obtain stable item statistics

Og lige en kommentar fra en far - hold dig væk fra min søn!

all items must be pretested with a large enough sample to obtain stable item statistics

Ja, men de har jo netop også kørt dem på prøveklud-elever først, og afprøvet opgaverne i forløb i 2008 og 2009. Jeg må antage at fuldtidsstatistikere har beregnet på hvad der var en forsvarlig størrelse, og jeg mindes ikke nogen kritik af den del af projektet.

Du finder mere på:
http://www.evaluering.uvm.dk/

- et ellers fantastisk arbejde, hvis bare vi kunne blive fri for alle de bedrevidende folk der ikke har sat sig ordentligt ind i det de taler om

Jeg skal da gerne indrømme, at jeg ikke for alvor ved hvad det drejer sig om - det er ikke mit arbejdsområde.

Jeg synes problematikken er spændende og ville derfor indgå i dialogen for at prøve nogle synspunkter af.

"bedre-gættende" er vel mere passende.

Udover sporadiske forsøg på at designe et system synes jeg også tråden handler om at gætte hvad der kan få det til at gå så galt. Det er da lærerigt - og ikke rent "show-off"

Hvis brugere der er logget ind laver tunge beregninger de betaler for og dem der ikke er logget ind ikke gør og ikke betaler. Så tror jeg du hurtigt vil komme til at stå til regnskab for hvor mange samtidige brugere dit system kan klare og ikke hvor mange requests/sekund det kan klare. På samme måde, uanset om Cowi har designet deres system med 100 Ajax-kald pr sidevisning eller et enkelt kald per sidevisning, så kommer de til at stå til regnskab for hvor mange samtidige brugere der kan være på systemet. Så tror jeg at kunden er ret liggelad med at de kan fremvise imponerende tal for hvor mange requests de klarer pr. sekund.

Det er da bedøvende ligegyldigt hvor mange brugere der er logget ind - igen husk på HTML er stateless.

Om der så er en milliard brugere "logget ind", som ikke laver en dyt, ja så sker der altså heller ikke noget på serveren.

Det er først når brugerene begynder at vågne op det er interessant, nemlig hvor mange samtidige brugere (repræsenteret ved request/datatransmissioner, call it what you want)) kan der håndteres.

Og mht. tunge brugere som laver mange beregninger (og prisen for det), så det ikke rigtig relevant i denne kontekst, da brugerne er at anse for ret uniforme.

/Christian

Det er klart interessant at få et input fra en lærer på hvorledes testen foregår - det er der også en del der efterlyser.

Desværres er jeg lidt ked af at læse denne pasus:

men alle dem der ikke har gjort deres hjemmearbejde: hold jer venligst væk

som meget nemt kan fortolkes som arrogant.

Især fordi du også siger du er it-vejleder, og derfor nok kan høste en del viden herinde, som du forhåbentlig vil finde nyttigt - uden at der herinde fra bankes i hovedet om at blive væk fordi man ikke har gjort sit hjemmearbejde.

Det må være muligt at udveksle erfaringer på en konstruktivt vis, og husk også at mange skibenter herinde både er skatteborgere (og dermed er ret rystet over det beløb der har medgået til dette eventyr) [b]og[/b] faktisk også er forældre til de børn der er kunder i folkeskolen.

/Christian

HTML er stateless

Lille rettelse: [b]HTTP[/b] er stateless.

Er det et problem, at gemme programmets state på serveren f.eks med AJAX, og have beregningsopgaven på clientsiden?

Hvis beregningsopgaven lægges på serversiden, vil den naturligvis betyde problemer, når mange bruger systemet samtidigt. Er den på clientsiden, er belastningen meget lille på serverside.

Jeg kan ikke se problemet i, at have en clientside løsning, bortset fra, at load-tiden, måske er 10 gange større. Men ingen siger, at hele java programmet skal hentes på éen gang - i princippet, kan der være éen per opgave, der så hentes af den forrige opgave, eller af en fælles java komponent.

Umiddelbart, burde det ikke være et problem, at håndtere mange tusinder brugere på éen gang.

Sikkerheden, er måske lidt større, hvis den placeres på serverside. Men at "hacke" programmet, tror jeg er usandsynligt - dels vil det nok opdages, hvis eksaminderne overvåges, og det vil tage langt længere tid, end at løse opgaverne. Loades java koden efterhånden som spørgsmålene besvares, kan pointudregningen, måske lægges i det næste java program som hentes, baseret på hvad der besvares for spørgsmålet. Det betyder, at eleven ikke umiddelbart kan se point, og svaret. Hvis der lægges en smule PHP kode på serveren, f.eks. således at PHP filen der kontaktes, og returnerer med java koden, udskiftes afhængigt af parametre til PHP'en, så opnås en tilstandsmaskine, der gør at når der svares, på et spørgsmål, så skiftes tilstand, så det ikke er muligt at aflæse resultatet (og point), før der er svaret - og når først der er svaret, så vil ikke være muligt at forsøge igen, da PHP filen på serveren udskiftes, og dermed er i ny tilstand. Det vil kun fylde ganske få liniers PHP kode, og PHP koden kan gøres kort.

Så vidt jeg kan se, vil det ikke være muligt at bryde, da point først kommer efter svaret på spørgsmålet er hentet, og samtidigt skiftes tilstand på serveren, ved at PHP'en udskiftes. Umiddelbart gætter jeg på, det kan gøres på ca. 3 - 5 PHP linier.

Skal man lave noget, der tåler stor belastning, er det bedste at 1. undgå databaser på serversiden, 2. undgå fælles filer, 3. undgå serverside programmering, eller holde den absolut minimal, og 4. at placere beregning og intelligens i javakode, der udføres på klientsiden. Hver bruger, skal helst skrive i egne filer, så der ikke behøves tilgang til fælles filer, andet end read-only.

Dette burde være forholdsvis fundemental, og være en beslutning der tages fra start, før man går igang med at programmere umulige opgaver, der kræver adgang til fælles data lagt i en kæmpe database, som ikke er designet til at løse opgaven.

Hvis beregningsopgaven lægges på serversiden, vil den naturligvis betyde problemer, når mange bruger systemet samtidigt. Er den på clientsiden, er belastningen meget lille på serverside.

Nej da, ikke hvis serveren er dimmensioneret ordenligt og beregninger skrevet fornuftigt. Ser du facebook, Amazon, Google m. fl. have disse problemer?

Jeg kan ikke se problemet i, at have en clientside løsning, bortset fra, at load-tiden, måske er 10 gange større.

Hmmm... der er mange problemer i en client side løsning - hele vedligeholdelsesdelen er forfærdelig - da det er et vældig heterogent miljø. Load tid er da et problem, det belaster da serveren.

Men ingen siger, at hele java programmet skal hentes på éen gang - i princippet, kan der være éen per opgave, der så hentes af den forrige opgave, eller af en fælles java komponent.

Det er vist ikke så KISS agtigt.

Umiddelbart, burde det ikke være et problem, at håndtere mange tusinder brugere på éen gang.

Nu skriver du selv Java, så jeg går ud fra at du tænker Java Web Start med RMI på EJB. Nej det man godt. Problemfrit nej. TCO er dog normalt lavere ved en ren webløsning.

Sikkerheden, er måske lidt større, hvis den placeres på serverside. Men at "hacke" programmet, tror jeg er usandsynligt - dels vil det nok opdages, hvis eksaminderne overvåges, og det vil tage langt længere tid, end at løse opgaverne. Loades java koden efterhånden som spørgsmålene besvares, kan pointudregningen, måske lægges i det næste java program som hentes, baseret på hvad der besvares for spørgsmålet. Det betyder, at eleven ikke umiddelbart kan se point, og svaret. Hvis der lægges en smule PHP kode på serveren, f.eks. således at PHP filen der kontaktes, og returnerer med java koden, udskiftes afhængigt af parametre til PHP'en, så opnås en tilstandsmaskine, der gør at når der svares, på et spørgsmål, så skiftes tilstand, så det ikke er muligt at aflæse resultatet (og point), før der er svaret - og når først der er svaret, så vil ikke være muligt at forsøge igen, da PHP filen på serveren udskiftes, og dermed er i ny tilstand. Det vil kun fylde ganske få liniers PHP kode, og PHP koden kan gøres kort. Så vidt jeg kan se, vil det ikke være muligt at bryde, da point først kommer efter svaret på spørgsmålet er hentet, og samtidigt skiftes tilstand på serveren, ved at PHP'en udskiftes. Umiddelbart gætter jeg på, det kan gøres på ca. 3 - 5 PHP linier.

Skaber du ikke en hel masse kompleksitet der ikke er behov for? Jeg har svært ved at se fidusen må jeg sige.

Skal man lave noget, der tåler stor belastning, er det bedste at 1. undgå databaser på serversiden, 2. undgå fælles filer, 3. undgå serverside programmering, eller holde den absolut minimal, og 4. at placere beregning og intelligens i javakode, der udføres på klientsiden. Hver bruger, skal helst skrive i egne filer, så der ikke behøves tilgang til fælles filer, andet end read-only.

Du har lige beskrevet Apache HTTPD - vi kan være enige om at den skalerer godt.
1. Nej man behøver absolut ikke undgå databaser på serverside - men man skal bruge den rigtige type database og man skal bruge den rigtigt.
2. Det behøver man absolut ikke, det skal bare gøres rigtigt. Din jnlp fil til er da også fælles og delt.
3. :-) nej man skal ej. Tror du ikke servere tåler stor belastning? Hvad er det for en tese du bygger det udsagn på? S/390 programmer tåler faktisk temmelig stor belastning.
4l. Kan du ikke fortælle det til bankerne, jeg tror gerne de vil købe dit koncept. Nu kan du ikke komme til at skrive i filer fra din Java kode på klienten. Men hvordan er det du har tænkt dig at summere samtlige transaktioner hos Danske Bank på klienten og fremvise dem? ved at opverføre hele basens indhold til klienten og så tælle sammen med en iterator?

Dette burde være forholdsvis fundemental, og være en beslutning der tages fra start, før man går igang med at programmere umulige opgaver, der kræver adgang til fælles data lagt i en kæmpe database, som ikke er designet til at løse opgaven.

Enig i at man skal tage beslutninger om arkitektur inden man programmere, men man har altså lov til at blive klogere mens man programmere, og omsætte den opnåede viden til handling, og så juster kursen. Ellers er man langt ude.
Men dine slutninger omkring kæmpe base, og hvad der tåler stor belastning er forkerte, så pas på med at besere dine løsninger på disse udsagn.

Det er da bedøvende ligegyldigt hvor mange brugere der er logget ind - igen husk på HTML er stateless.

Ikke når brugsmønsteret er kendt, så kan det direkte afspejle requests/sekund.

Om der så er en milliard brugere "logget ind", som ikke laver en dyt, ja så sker der altså heller ikke noget på serveren.

Men det gør de jo ikke, brugsmønsteret er kendt

Det er først når brugerene begynder at vågne op det er interessant, nemlig hvor mange samtidige brugere (repræsenteret ved request/datatransmissioner, call it what you want)) kan der håndteres.

Nu snakker du selv om samtidige brugere?

Og mht. tunge brugere som laver mange beregninger (og prisen for det), så det ikke rigtig relevant i denne kontekst, da brugerne er at anse for ret uniforme.

Netop derfor giver det god mening at tale om samtidige brugere i dette tilfælde.

Lille rettelse: HTTP er stateless.

Ja selvfølgelig, sorry, my bad.

/Christian

Netop derfor giver det god mening at tale om samtidige brugere i dette tilfælde.

Tjae det bliver vi så nok ikke enige ud, ud over at man selvfølgelig godt kan tale om samtidige brugere, hvilket afspejles i antal request*datamængde/tidsenhed.

Men antallet af indloggede brugere fastholdes nuengang kun vha. en session/cookie variabel, og repræsenterer ikke nødvendigvis load.

Men klart at hvis der er 15.000 brugere der skal bruge systemet til at svare på hver 20(?) spørgsmål i løbet af en time, så kan man godt lave en beregning på forventet belastning.

/Christian

Som jeg forstår adaptiviteten, er den ikke større, end det kan gøres med en tilstandsmaskine på serveren. Ved en given opgave, er der mulighed for at sværhedsgraden skal øges, mindskes, og naturligvis de svar muligheder som er for opgaven. Det vil kunne implementeres som næste tilstand = kodefornæstetilstand+svar, hvor svar er svaret som java koden returnerer med, og vil sværre, lettere, eller svaret på opgaven (f.eks. A..E) hvis der er fem svarmuligheder. Ved hvert svar skiftes tilstand, afhægig af svaret, og stigende/faldende sværhed. Om opgaverne skal blive sværre eller lettere, kan regnes ud i java koden, efter point. Point behøver ikke at stå i java koden, på det tidspunkt opgaven gives, men kan stå i den kode, der hentes når svaret leveres. Da tilstanden samtidigt skifter, er ikke muligt at gå tilbage, og "rette" i opgaven, på tidspunktet hvor point står i java koden.

[quote]Hvis beregningsopgaven lægges på serversiden, vil den naturligvis betyde problemer, når mange bruger systemet samtidigt. Er den på clientsiden, er belastningen meget lille på serverside.

Nej da, ikke hvis serveren er dimmensioneret ordenligt og beregninger skrevet fornuftigt. Ser du facebook, Amazon, Google m. fl. have disse problemer?[/quote]Teoretisk kan du altid dimmensionere dig ud af et belastningsproblem... I praksis, er det også et spørgsmål om metoder og algorithmer. Har du effektive metoder og algorithmer, og laver effektive forespørgsler i din database, så vil du sædvanligvis kunne løse problemet, ved at anvende tilstrækkelige kraftige, eller tilstrækkeligt mange servere.

Jeg kan godt se, at jeg fik det formuleret forkert.

Problemet med databaser, er at der kan laves forespørgsler, der tager tid og er komplekse.

Problemet med fælles filer der er åbne for skrivning, at de ved forkert brug kan blokere.

Problemet med serverside programmering, er at det er muligt, at lave kode, der udsulter serverens datakraft.

Problemet med beregninger og intelligens på server siden, er at den kan kodes, således at serverens datakraft udsultes.

En mulig løsning, kan være at undgå ovenstående. Det betyder dog ikke, at det er eneste løsning - som jeg fik det til at fremstå som. Men anvender du databaser, anvender du serverside programmering, og anvender du fælles filer, som der skrives i, så skal det gøres med et vist omhu.

15.000 elever (ikkesamtidige, men lad os alligevel antage)
50 spørgsmål fra en pulje af 500 skal besvares på en time

Et svar på et spørgsmål kan gemmes på 1 kb (meget højt sat) - dvs. en elevs fulde tilstand kan gemmes på maximalt 50 kbyte.

Der er ingen afhængigheder mellem elevers besvarelser - dvs. låsning osv. er uproblematisk. Det eneste der skriver til en elevs besvarelser, er eleven selv.

Det fulde lagerbehov for alle elever er således 732 mbyte. (!!!)

Vi kan antage en belastning på gennemsnitligt 250 besvarelser/sekund. I tilfældet hvor alle starter testen samtidig, vil der komme en højere spidsbelastning, men den er i store træk ligegyldig da den ikke har nogen beregninger tilknyttet (næsten statisk data) - og så er 15.000 forespørgelser på få sekunder intet problem.

Disse fakta givet, skalerer løsningen fuldstændigt lineært med antallet af elever. Hvis det er designet nogenlunde fornuftigt kan man smide mere billig hardware efter problemet og få 100% udbytte af hver ekstra server.

Jeg tror det afgørende spørgsmål her er, "Hvor henvender man sig for at byde på Undervisningsministeriets IT-projekter, og er det ikke ved at være tid til at købe den privatjet?"

men den er i store træk ligegyldig da den ikke har nogen beregninger tilknyttet (næsten statisk data) - og så er 15.000 forespørgelser på få sekunder intet problem.

Hvert spørgsmål fylder 1.46 megabyte i snit. Ved det første spørgsmål, må vi forvente at alle 15.000 starter i samme øjeblik, eller indenfor 10-20 sekundet. Hvis vi antager de starter i samme øjeblik, skal overføres 22 gigabytes, eller ca. 200 gigabit. Hvis det "kun" er en 4 gigabit forbindelse, så vil det tage ca. 1 minut.

Jeg tror, at mange elever, vil føle 1 minut som lang ventetid. Problemet kan naturligvis løses, hvis eleverne ikke logger på, på præcis samme tidspunkt - men bedre er det, hvis opgaven kan caches af en proxy server undervejes. Ved første opgave, er det jo samme opgave, at alle eleverne henter. Så hvis den gemmes under samme path og filnavn, således proxy serveren kan genkende det, vil det ikke være et problem.

I den grad, at det er muligt, er måske en fordel at hente samme spørgsmål fra samme path/filnavn. Med proxy servere undervejs, er der ingen større belastningsproblem.

Naturligvis skal data gemmes på serveren, men mængden af disse data er meget små, og tager kun kort tid at opbevare. Jeg gætter på, at det er muligt at opnå langt over 15.000 samtidige brugere, hvis der er proxy servere undervejs, og at spørgsmålene caches i proxyerne.

Med 250 besvarelser per sekund, og en overførsel på 1-2 kbyte for hver besvarelse, er det en spidsbelastning på 500 kilobyte per sekund. Dataene vil i første omgang overføres til en ram-cache, så harddiskens hastighed betyder mindre. Data overføres til harddisk fra cache, meddens opgaverne besvares, så det indgår ikke i den kritiske tid.

Det burde være muligt, at have langt flere end 15.000 på éen server, hvis der er proxy servere undervejs. Jeg gætter på, at 200.000 ikke vil give problemer, hvis opgaverne caches af proxyer.

Ved udviklingen af opaven, er derfor også relevant, at se på om filnavne og sti, for ens opgaver muliggør caching.

Jeg tror det afgørende spørgsmål her er, "Hvor henvender man sig for at byde på Undervisningsministeriets IT-projekter, og er det ikke ved at være tid til at købe den privatjet?"

Jeg tror ikke privatjet er nok, med mindre den pakkes ind.

"Good point" med proxys.

Måske har du også lige givet forklaringen på, at belastnings testen kunne udføres uden problemer.

Her har en proxy måske hjulpet serveren.

I live situationen sidder der måske kun 50 elever pr. proxy = 300 proxys, der skal fodres. Lyder måske ikke af meget, men kan dog være en anden virkelighed end belastningstesten.

.. flere gætterier :-)

Hvert spørgsmål fylder 1.46 megabyte i snit.

Hvor i alverden har du den fra?

Hvis der er nogen der kan få disse så simple spørgsmål til at fylde [b]1,46 Megabyte per stk[/b] så er vi vist ude i noget med offentlig afstraffelse og gabestok!

/Christian

Teoretisk kan du altid dimmensionere dig ud af et belastningsproblem... I praksis, er det også et spørgsmål om metoder og algorithmer. Har du effektive metoder og algorithmer, og laver effektive forespørgsler i din database, så vil du sædvanligvis kunne løse problemet, ved at anvende tilstrækkelige kraftige, eller tilstrækkeligt mange servere.

Nu handler det for mig for det meste ikke om at "løse problemet", det handler om ikke at skabe sig et problem - og der er vi nok enige.

Du så er fortaler for Web start og tykke klienter - det er jeg ikke.
Der er flere problemer med dem, udover vedligeholdelse mm..
Een af de store er fornuftig skalering (som ser ud til at være problemet i det her tilfælde).
Den distribuerede tykke klients løsning har nemlig for det meste kun 2 mulighede for at være forbundet med back end:
1. RMI (hvor der er en Application Server på backend som så styre adgang til ressourcer).
2. Den kan selv forbinde til ressource såsom databaser.

I begge tilfælde skaleres dårligere end webløsnigen (der kun kræver tilstandløs forbindelse fra klienterne, og derfor effektivt kan poole sine resourcer).
Da der i RMIs tilfælde er tale om en tilstandsfuld forbindelse, som er dyr og tung (og du skal bruge een for hver klient - også dem der sover), får du et system med en langsom responstid, og venten, samt du risikerer simpelthen at udsulte serveren. Derudover er der jo en hel del serverprogrammering i sådan en løsning.
Ellers skal du lave n forbindelser til databasen (samt de andre systemer du vil snakke med), hvor n er antallet af klienter (et paradigme vi har forladt for det begynder at gå rigtig skævt når vi når omkring 100 forbindelser), eller du skal konstant åbne og lukke forbindelser, hvilket er super langsomt.

Fordelen ved den konsoliderede web løsning, er at den giver endda meget gode muligheder for skalering, udnyttelse og throttling af ressource, i forhold til den distribuerede, da du et knudepunkt som du selv kontrollerer, der har adgang til ressourcerne. Derudover er den væsentlig simplere at skrue sammen og deployere.

I det distribuerede setup, forbinder samtlige klienter jo fuldstændig autonomt, så du har ikke en Kinamands chance for at finde hoved og hale i hvad der foregår - endnu sværere bliver det er belastningsteste.

Når det så er sagt, findes der rigtig nok situationer hvor disse applet-baserede systemer faktisk virker ganske fint (ud over at Swing ikke er fint overhovedet), nemlig i et miljø hvor der er total kontrol (DSB billetsalg, intern SKAT osv.). Men jeg tvivler stærkt på de vil lave en hel masse flere af dem.

Desværres er jeg lidt ked af at læse denne pasus: men alle dem der ikke har gjort deres hjemmearbejde: hold jer venligst væk som meget nemt kan fortolkes som arrogant.

Hvis du (eller andre) opfatter det som arrogant, vil jeg gerne beklage - det var absolut ikke meningen!

Nok nærmere et (fejlplaceret) surt opstød over hvor mange der mener de ved alt om folkeskolen og nærmest er eksperter - de har jo selv været der...
Selvom folkeskolen til tider kan være sværd at rykke (specielt når det drejer sig om it - uha, der er mange it-forskrækkede lærere og ledere), så sker der altså en pæn del - og skolen ser langt fra ud som den gjorde for 15 år siden.

og husk også at mange skibenter herinde både er skatteborgere (og dermed er ret rystet over det beløb der har medgået til dette eventyr) og faktisk også er forældre til de børn der er kunder i folkeskolen.

Tja, jeg betaler jo også skat, og jeg er også rystet over hvilke beløb der er brugt på dette. MEN husk nu på at de beløb der nævnes jo langt fra alle er gået til det it-tekniske. En meget stor del (kender ikke pct. tallene, men vil antage at det er den langt overvejende) er jo gået til udarbejdelsen af opgaver, hvilket jo intet har med it at gøre (netop it kompentancerne vi skal lærere eleverne testet ikke i de elektroniske nationale test...)

Hvert spørgsmål fylder 1.46 megabyte i snit. Hvor i alverden har du den fra?

Baggrunden var Martin Seebach's indlæg, der skrev de 500 opgaver fyldte 732 mbyte, hvilket jeg fik til 1.46 MB per spørgsmål. Imidlertid, er de 732 MByte, ikke det at opgaverne fylder, men den plads der bruges på at opbevare programmets tilstand på serveren, og dermed falder de 1.46MB til jorden. Opgaverne burde fylde i størrelsen under 100KB, selvom de måske indeholder billeder. Indeholder de film, kan de måske være større, men 1.46MB er bestemt for meget i snit. Det er dog ikke en størrelse, som er umulig, hvis opgaverne indeholder java og film, eller måske flash.

Du så er fortaler for Web start og tykke klienter

Jeg kan ikke se sammenhængen med webstart. Hvis du ser på opgaverne, der f.eks. går ud på at placere et tal på en tallinie, så mener jeg at software på clienten, er den eneste rette løsning. Det kan være en java, eller flash løsning.

Jeg argumenterer ikke imod scripts på serveren. Men opgaven for serveren, kan begrænse sig til en tilstandsmaskine, således næste opgave hentes ind afhængigt af hvilken tilstand serveren befinder sig i. Dette er en ganske lille opgave, som jeg mener kan klares med ca. 5 PHP linier.

I nogle sammenhænge, kan det være en fordel med databaser på serveren. Umiddelbart, kan jeg ikke se et problem i, at tilføje besvarelserne til en database når opgaverne besvares, men åbentbart er mange muligheder for faldgrupper. Hvis databasen, ikke kan håndtere mange uafhængige requests og svare hurtigt, så kan løsningen være, at opbevare data i individuelle filer for hver elev på serveren, og overføre disse til databasen med et script, når eksamen er forbi. Dette burde dog, være en helt unødigt operation.

Under alle omstændigheder, er opgaven på serveren ganske simpel: Afhængig af opgavens besvarelse, går serveren til en ny tilstand, og leverer en ny opgave afhængigt af tilstanden. Dette tager kun få liniers serverkode. Eventuelt, kan opgave og svar herpå, opbevares i en database. Hvis dette volder kvaler af underlige årsager, så kan det være en mulighed at opbevare data i en fil på serveren indtil eksamen er forbi, og overføre det til database herefter med et script, for alle eleverne. Her betyder det ikke meget hvor lang tid scriptet tager og databasens hastighed.

Selve opgaven, overføres fra serveren til clientcomputeren, og den vil typisk være skrevet i Java, for at kunne opfylde det som kræves.

Udover en tilstandsmaskine på serveren, er nødvendigt med pointudregning. Det nemmeste er måske at gøre dette på serveren, men det er også ganske simpelt. Selvom pointudregning lægges på serveren, mener jeg ikke, at det er nødvendigt at udføre mere end ca. 10 liniers meget simpel PHP kode, for hvert svar der besvares, og måske mindre. En server burde nemt kunne klare 15.000 requests eller mere samtidigt, uden at blive overbebyrdet.

Hvis det havde været en ekstrem kompliceret opgave for serveren, og ikke kun en tilstandsmaskine, så kunne en løsning være, at lægge en del af regnekraften over på klienten, for at aflaste serveren. I tilfældet her, er opgaven meget simpel, og den vil nemt kunne køre på serveren, næsten uanset antallet af samtidige brugere. Eneste funktion, er en tilstandsmaskine, hvor næste tilstand afhænger af opgavebesvarelse og point, og intet andet. Dertil, skal point udregnes afhængigt af besvarelsen, hvilket sandsynligvis ikke er andet end en plus operation.

Jeg kan ikke helt gennemskue din tilstandsmaskine. Hvor mange tilstande skal man bruge, hvis man skal løse 50 ud af 500 opgaver med 3 svarmuligheder for hver opgave?

Hvis du ser på opgaverne, der f.eks. går ud på at placere et tal på en tallinie, så mener jeg at software på clienten, er den eneste rette løsning. Det kan være en java, eller flash løsning.

Hvorfor ikke bruge det, som de rent faktisk bruger, nemlig JavaScript + HTML over HTTP?

Hvis du ser på opgaverne, der f.eks. går ud på at placere et tal på en tallinie, så mener jeg at software på clienten, er den eneste rette løsning. Det kan være en java, eller flash løsning.

Hvad er der i vejen med JS+CSS+HTML til at løse den opgave, det er vel lige så god teknologi som det du nævner - samt du er sikker på at alle browsere (flamebait?) kan afvikle det.

Men det du argumentere er nu at vi skal kode på klienten for brugeroplevelsen, hvor det før var fordi vi skulle lade være med at kode på serveren?
Jeg forstår ikke hvor du vil hen. Desuden har du nu flyttet al logik til serveren , hvor du før beskrev at det havde vi ikke brug for.
Du nævner bla. server side skrivning til filer som skal flyttes til basen (det er i mine øjne en overkomplicering af opgaven).
Server side tilstandsmaskine - så vi nu har en tilstandsfuld client/server løsning. PHP kode (selvom man kan skrive alle disse ting med maksimalt 5 liniers PHP efter hvad du siger)

Din tilstandsmaskine vil jeg gerne se dig skrive i 3-5 liniers PHP, specielt en tilstandsmaskine til den her opgave.
Jeg ville nok foretrække noget workflow/rules baseret, såsom drools 5 til sådan en opgave, men bevares.

Hvis det havde været en ekstrem kompliceret opgave for serveren, og ikke kun en tilstandsmaskine, så kunne en løsning være, at lægge en del af regnekraften over på klienten, for at aflaste serveren.

Du kan altså ikke transportere regnekraft fra server til klient. Du kan flytte regneopgaver derud, hvilket kræver en forudsætning om at der er regnekraft nok til stede. Det har vi da ingen garanti for. Desuden skal du så også være sikker på at klienten rent faktisk kan regne den slags opgaver. Databaser (eller de fleste af dem) er rent faktisk optimeret til at lave beregninger, og jo større beregningerne er jo bedre er de løst på servere.
Tilbage til bank situationen som du ikke svarede på: Skal de virkelig transportere data fra deres DB2 til klienten for at aggregere data der, eller skal de gøre det på serveren som er designet til det, og så nøjes med at transportere resultatet?

Du kan flytte regneopgaver derud, hvilket kræver en forudsætning om at der er regnekraft nok til stede. Det har vi da ingen garanti for.

Garantier skal man være varsom med at udstede, men se fx her:
http://www.version2.dk/artikel/13752-et-interrupt-en-pipeline-og-en-koe-...
Der er meget kraft i en standard computer.

Det er ikke muligt at sige hvad den korrekte løsning er. Ofte afhænger det af medarbejderne. Hvis de ønsker at lave en serverbaseret løsning, der anvender databaser - så vil det kunne være dumt, at sætte dem til andet. De vil nemt, kunne få en klientbaseret løsning, til at køre dårligere, end den serverbaserede løsning, som de mener kører bedst.

Omvendt, vil dem der mener en klientbaseret løsning er bedst, ikke nødvendigvis være bedst til at udvikle en serverbaseret løsning. Måske får de serveren til at være alt for sløv til formålet.

Som jeg ser det, er det et problem, at mange ikke er opmærksomme på, hvor store resourcer et problem kræver. Dette problem, eksisterer på både serverside, og på clientsiden. Programmørerne, anvender måske metoder, der er sløve, og har ikke undersøgt hastigheden for de tools de bruger.

Med hensyn til en tilstandsmaskine, så kan det gøres så programmets størrelse er ens, uanset størrelsen af tilstandsmaskinen. Det kan også gøres, ved at lave megaenorme scripts, der ender i dødskørsel. Derfor kan ikke siges, at det er løsningen. Enhver løsning, kan forplumres, så den viser sig umuligt at implementere, hvis det er det som programmørene kan, eller ønsker at opnå.

Som eksempel på en tilstandsmaskine, kan næste tilstanden opnås, ved at udskifte et script på harddisken. Næste script, kan læses fra et katalog, hvor navnet er en næstetilstandskode, plus eventuelle parametre.

De fleste løsninger, vil bero på både software på serverside, og clientside. I nogle tilfælde, kan opgaven jungleres mellem server og clientside, så programmørerne vælger, hvor kompleksiteten skal lægges. En server, har stort set ikke større datakraft, end nogle få PC'er, så udfra et belastningsmæssigt synspunkt, vil der ved større belastning af en server, være en fordel at plaere belastningen på client siden - på den anden side, så kan en programmør, der ønsker at lave om på dette, gøre det ved at øge kompleksiteten på clientsiden til at være mange gange større, end på serversiden. Og i den sidste ende, kan programmøren derfor vælge at løse opgaven, så den er tung.

Har medarbejderne ikke viljen, til at lave en løsning, der ikke belaster server eller client nævneværdig, så kan de altid udvikle softwaren så der kræves en høj belastning. Også ledelsen, kan ustikke retningslinier og krav, der gør at programmørerne umuligt kan løse en opgave, så den kan udføres med lav belastning. I den sidste ende, er det ledelsen der bestemmer, og derfor også dem der har ansvaret, og må gå ved skandaler.

I den sidste ende, er det ledelsen der bestemmer, og derfor også dem der har ansvaret, og må gå ved skandaler.

Nemlig :-)

Der er meget kraft i en standard computer.

Sikkert, men så antager du jo at dit program bliver afviklet på en standard computer.

Sikkert, men så antager du jo at dit program bliver afviklet på en standard computer.

Nej jeg antager ikke noget som helst. Jeg prøver at illustrere at man sagtens kunne antage noget. Jeg har prøvet ovenstående test på en subnote der er 7 år gammel og den kunne stadig klare over 100.000 svar. Så hvis man har lyst til at antage noget, er der god basis for at antage et minimum som alle skolers computere kan tilfredsstille. Der er massa' kraft i klienterne...

Der er massa' kraft i klienterne...

Det er der nemlig :-)

@Nikolaj

Men har de da det - transport veje problemer?

Hvis man går ud fra at det er mere end bare trivielle sider man skal hente, så kan man jo sige at siden fylder godt oppe omkring de 200-500kb (et par billeder, noget tekst, og nogle spørgsmål).

lad os sige 15 000 bruger som tallet nævner, så ligger serveren og skulle levere op til 7500 000 000 bytes skal levers hurtig. Altså ca 7.5Gbytes af da skal ligges ud, Har serveren 100 Mbit til rådighed, er det 75 sekunder før den er færdig med dette, hvis man kan regne med 100% brug, som man langt fra kan, pga alt den overhead der er i systemet. Ligger man så et par film klip, ind, så bliver problemet hurtig værre.

men 75 sekunder er 1 minut 15 sekunder, og det er ideal tilfældet.

Jeg regner med at serveren har mere til rådighed.

Men du skaber jo også en hel del i dit setup, se bare på dem som Jesper outliner.

Distribueret systemer har problemer med at der skal mere vedligehold til, men de har langt færre problemer med skalerbarhed, throughput, og beregningskraft, end en centraliseret løsning har. Hvad man spare et sted taber man et andet - generelt set.

Hvad er ret meget? Tror du ikke de har nok til en gang HTML/Flash eksamen, det tror jeg, ellers er det nok bedre at investere pengene her, end i dyrt hardware som de kan smide ud om nogle år, da det er forældet. Jeg tror i øvrigt ikke på er et problem, på mange skoler sidder eleverne allerede og ser Youtube og Flash, uden problemer, hvorfor skulle de ikke kunne det til en eksamen.

Ret meget, 20-30Mbit/sek, mange områder har ikke sådanne hastigheder, selv om de er på vej.

Dyr hardware, en almindelig PC (<10 000), med et par harddiske kan ganske snildt agere proxy for web caching, og video caching, jeg nævnte kun en dyr 3 server proxy løsning som worst-case, for virkeligt store skoler som vi ikke har her hjemme.

Der er en væsentlig forskel mellem at sidde og se You-tube i din fritid og eksamen. For det første er det ret usandsynligt at alle se den samme video klip, på den samme tid, desuden er de ikke under et tids pres, og kan godt vente 2-3 minutter for at komme klippet igennem, og desuden kommer det mig bekendt ikke fra en enkelt server, men fra et ret stort distribueret cluster.

Sagde du ikke at du betvivlede at skolen havde høj båndbredde, og nu snakker vi 100Mbit? Nå men hvis du vil have et tip til en firewall som kan, er IP-filter gratis og den kan.

Beklager jeg ikke var helt tydelig, her taler jeg om serveren, hvor de levere dataere fra, den server regner jeg med er beskytte af en firewall, vil jeg da tro. Jeg har selv arbejdet på systemer, og ved at firewalls der kommer over 100 megabit through put hurtigt kommer op i million klassen prismæssigt - fra de sidste projekt jeg kørte med video transmission fra lidt over 2000 kilder til en opbevarings server.

Hvis man går ud fra at det er mere end bare trivielle sider man skal hente, så kan man jo sige at siden fylder godt oppe omkring de 200-500kb (et par billeder, noget tekst, og nogle spørgsmål). lad os sige 15 000 bruger som tallet nævner, så ligger serveren og skulle levere op til 7500 000 000 bytes skal levers hurtig. Altså ca 7.5Gbytes af da skal ligges ud, Har serveren 100 Mbit til rådighed, er det 75 sekunder før den er færdig med dette, hvis man kan regne med 100% brug, som man langt fra kan, pga alt den overhead der er i systemet. Ligger man så et par film klip, ind, så bliver problemet hurtig værre. men 75 sekunder er 1 minut 15 sekunder, og det er ideal tilfældet. Jeg regner med at serveren har mere til rådighed.

Hvordan er det et svar på om de har transport veje problemer?
Desuden er din beregning med 200-500kb, så 7.500.000.000 er vel maksimal belastningen. Og den tror jeg godt Amazon EC2 kan klare. Desuden vil det sikkert blive cached af skolens proxy.

Distribueret systemer har problemer med at der skal mere vedligehold til, men de har langt færre problemer med skalerbarhed, throughput, og beregningskraft, end en centraliseret løsning har. Hvad man spare et sted taber man et andet - generelt set.

Skalerbarhed, it depends.

Dyr hardware, en almindelig PC (<10 000), med et par harddiske kan ganske snildt agere proxy for web caching, og video caching, jeg nævnte kun en dyr 3 server proxy løsning som worst-case, for virkeligt store skoler som vi ikke har her hjemme.

Har du set priserne hos Amazon for nyligt? Så er selv. 5.000,- dyrt.

og desuden kommer det mig bekendt ikke fra en enkelt server, men fra et ret stort distribueret cluster.

Det kan du også sagtens lave med Amazon EC2.

Jeg har selv arbejdet på systemer, og ved at firewalls der kommer over 100 megabit through put hurtigt kommer op i million klassen prismæssigt - fra de sidste projekt jeg kørte med video transmission fra lidt over 2000 kilder til en opbevarings server.

Hvis man vil lege med BigIP, Netscaler osv. så ja - det bliver dyrt. Men det er der heller ingen grund til. Ligesom der ingen grund er til at købe Oracle WebLogic, men virksomheder gør det alligevel.
Et system som dette egner sig godt til skyen, da der kan skrues op for beregningskræfterne når der er brug for det. Dette kan iøvrigt ske dynamisk, og dermed betaler man kun for den datakraft man bruger, og systemet er dermed skaleret til belastningen, om der er 1 bruger eller 5.000.000 brugere. Det gør at infrastrukturen er forholdsvis simpel (simpel == billig), og at der kun betales for den når den benyttes.
Lad os sige at 2.000 skoler gik til eksamen og det tog dem 5 timer. Man kunne så købe en server hos Amazon til hver skole i 6 timer (så er der 30 min. til opstart og 30 min. til at overføre opsamlede svar bagefter). Det ville koste: 2.000 * 6 * $0.085 = $1020, altså < 10.000,- for al beregningskraften der skal bruges til en landsdækkende eksamen. Det er sgu billigt. Eller < 5,- pr. skole (kan ikke lige regne ud hvad det bliver pr. elev, men ikke meget).

@Nikolaj

Hvordan er det et svar på om de har transport veje problemer? Desuden er din beregning med 200-500kb, så 7.500.000.000 er vel maksimal belastningen. Og den tror jeg godt Amazon EC2 kan klare. Desuden vil det sikkert blive cached af skolens proxy.

Vel og mærke hvis du antager at eleverne ikke sidder prøven på nær samme tid, som jo var postulateret i starten. Så alle disse data skal jo overføres på nærmest samme tid, det kan godt være det er forskudt et par minutter, men der vil stadigvæk været et stort sammenfald hvor alle henter data samtidigt.

Jeg nævnte 200-500kb som et eksemple, men hvis man som nogen har sagt benytter 1.45MB per spørgsmål, altså er min worst case nærmere best case, da den er 3x værre. Hvor man ville få over 1 minut vente tid, med en 300Mbit båndbredde ud fra serverne.

Men med de data mængder så er det nok streamed media, som ikke er cached, og derefter at man køre via https, som er endnu en blokering for at man kan cache, hvis man ikke har special proxies. Altså er det stor sandsynlig at skolens proxier ikke har virket.

Samtidig med at den adaptive process, kan medføre at alle eleverne på hver skole alle har hentet forskellige spørgsmål ned, som ville betyde at initielt, ville det gå godt, og efter en kort periode ville problemerne opstå

Det er mig ganske fint hvis man vil købe sig ind på distribuerede systemer, der har skalerings kapaciteten.

Problemet er bare, så er der et nedbrud et eller andet sted på internettet, og vi har dusiner af elever der ikke kan lave deres prøver, igen ville dette være ungået ved local hosting, og remote submission.

Centraliserede løsninger har mange single points of failures, som vil gøre sådanne systemer sårbare over for store problemer.

I øverigt prisen på pc'er var for at svare på at du postulerede det ville være dyrt - hvis jeg forstod dig rigtig.

Det er mig ganske fint hvis man vil købe sig ind på distribuerede systemer, der har skalerings kapaciteten. [quote]Problemet er bare, så er der et nedbrud et eller andet sted på internettet, og vi har dusiner af elever der ikke kan lave deres prøver, igen ville dette være ungået ved local hosting, og remote submission.

Hvis nettet er nede er det også nede i den distibuerede løsning, og så kan den altså heller ikke starte - no access to questions.
Brud på internettet, strømafbrydelse, jordskælv osv. er noget det er svært at gardere sig imod, og udgør en risiko. Bruddet vil dog kun påvirke den skole der ikke kan se serverne, ligesom hvis netkortet brænder af i den PC du vil stille der.

I øverigt prisen på pc'er var for at svare på at du postulerede det ville være dyrt - hvis jeg forstod dig rigtig.

Nu har jegikke påstuleret, jeg har beskrevet overfor dig hvad jeg anser som dyrt og billigt. Og for at gøre det lidt tydeligere, så kan regnestykket skrives sådan her: 2.000 skoler med 1 PC til 10.000 det er en startudgift på 20.000.000,- det er altså temmelig meget i min bog (det er så uden intallation og vedligeholdelse).
Jeg mener bare at man med løsningen hos Amazon EC2 eller Google AppEngine kan spare en hel masse af disse penge.

Centraliserede løsninger har mange single points of failures, som vil gøre sådanne systemer sårbare over for store problemer.

Centraliserede løsninger er single point of failure.
Distribuerede systemer, såsom systemer bygget efter SOA, har ligeledes mange single point of failures. Det centraliserede system i denne sammenhæng er jo virualiseret hos Amazon, så det startes igen. Hvis f.eks. PSU brænder af i din distribuerede maskine er der ingen eksamen på den skole.
Jeg er ikke nødvendigvis for centraliserede systemer, jeg synes distribuerede systemer er spændende, de er blot ikke trivielle, og der er mange ting der kan gå galt (der introduceres flere kommunikationsveje og der fordre en højere fejlrate).

Jeg mener derimod det er forkert at stille det op som, at centraliserede systemer er mere sårbare og har flere nedbrud end distribuerede systemer.
Eksempelvis er nogle af verdens mest stabile systemer centraliserede systemer: Mainframes, Webservere, Tandem/HP-nonstop.

Vi ser ofte store offentlige opgaver, falder til jorden af den ene eller anden årsag. Og ofte, er opgaverne af en art, så det må undre, at de ikke kan løses. Årsagen, tror jeg, er at man holder fast ved en bestemt løsning, en bestemt løsningsmetode, og måske bruger ledere og programmører, der er enige om løsningsmetode.

Ved store projekter, hvor penge tilsyneladende ikke burde være et problem, burde man vel egentligt lave flere hold, der søger at løse opgaven, med forskellige løsningsmodeller. Hvis det ene projekt så falder til jorden, kan et andet bruges. Og de forskellige resultater, kan sammenlignes med hinanden, så der findes den løsning, der er bedst.

Det koster naturligvis, at udvikle en opgave flere gange - efter forskellige metoder, men i forhold til de beløb der er på spil i de store projekter, så er disse udviklingsomkostningerne små. Fordelen, ved at opnå større leveringssikkerhed, og at have afprøvet flere metoder og dermed at kunne vælge den bedste metode udfra målinger af forsinkelse samt stabilitet, giver fordele, der er værd at betale for.

Det kan være svært at se begrundelsen, i så svimlende beløb, når det ikke er gjort noget for at sikre en god løsning, ved at have ladet forskellige programmører, med forskellige opfattelser, konkurere indbyrdes.

Ulempen ved licitationer, er at når først opgaven er vundet - så er det monopol. Dette medfører dårligere kvalitet, høj pris, og i nogle tilfælde mafielignende tilstande, hvor monopolmagten, bruges til at presse flere penge ud af kunden. Måske bør udbyderen derfor gøre det til et krav, at der udvikles forskellige koncepter som kan afprøves af kunden, og at opgaven deles op i etapper. Dette vil måske kunne mindske "monopol" effekten ved offentlige licitationer.

Ved store projekter, hvor penge tilsyneladende ikke burde være et problem, burde man vel egentligt lave flere hold, der søger at løse opgaven, med forskellige løsningsmodeller. Hvis det ene projekt så falder til jorden, kan et andet bruges. Og de forskellige resultater, kan sammenlignes med hinanden, så der findes den løsning, der er bedst.

Det er faktisk mange gange billigere i længden. Det hedder set-based development, og er en praksis Toyota bruger (Microsoft brugte den in-house med success til udviklinge af Outlook).
Du har helt ret, jeg mener ikke det begrænser sig til store opgaver men også små, og det gælder også udbudsmaterialer mv. (eller rapporter som den McKinsey lige har lavet). Det vil højne konkurrencen og skærpe profilerne, ligesom læring vil blive sat på dagsordnen. Et emne det virker som om er glemt her i videnssamfundet.
Godt skrevet Jens - jeg havde nær glemt det.