Test-skandalen: Her er spørgsmålene Cowi ikke vil svare på

• 486
• ?
• Peters kælder
• vi prøvede allesammen på kontoret på samme dag
• vi er blanke
• begge dele køres fra den samme computer
• nej
• ?
• Eleven trykker på sit navn i listen
• ?

Og du har så tydeligvis ingen viden om systemet.

Svømmeklap til dig.

For to år siden da jeg kom op i geografi testen. Blev vi sendt forbi UNI-C login siden.
Der var så nogen fra min klasse, som systemet slet ikke ville godkende :S

@Jesper Hansen
Hej, mit navn er humor.
Jeg savner dig! =(

On-topic:
Det må godt nok være pinligt hvis de ikke vil sige noget om så simple spørgsmål. Det er jo ikke fordi det meste af det tager vanvittigt langt tid at besvare.
@Alexander: Min lillesøster var op i disse prøver. Hun var ret 'traumatiseret' da hun kom hjem. Hun havde forberedt sig rigtig meget men det var bare ligegyldigt når ingenting virkede.

Det her svarer lidt til at komme op til en prøve og få at vide at posten er forsinket så prøverne først kommer i morgen. Det er ikke sjovt, og det er specielt uacceptabelt når det sker gang på gang.

Der er jo tale om en forholdsvis simpel database, for mig lyder det mest som en opgave på ret lavt niveau. Måske er der blevet brugt alt for avanceret programel og det ville så have været billigere at lave det hele med ganske almindelig programmering og helt fra bunden.

Hvem er friske på at gøre det bedre? Så kan vi sende COWI et tilbud på et system der virker ;)

@CHRISTIAN W. MOESGAARD
Er ualmindeligt træt af folk der prøver at være sjove/bashe det her projekt, når de tydeligvis ikke aner en skid om det.

Hvis man prøver demonstrations testene på http://demo.evaluering.uvm.dk/ ser det ud til, at der er mindst 2 HTTP requests pr spørgsmål - nemlig fodnote GIF og selve formen. Derudover kommer så én mere request pr. figur. Med en figur pr. spørgsmål og 7 spørgsmål i det hele er det altså 21 request pr. elev pr. test.

Det kunne naturligvis relativt nemt laves om til to requests - en der henter testen og en, der afleverer resultatet til serveren.

Om det så er på frontenden flaskehalsen ligger, skal jeg ikke kunne sige. Det skal Cowi åbenbart heller ikke.

@Jesper Hansen:
Jeg synes det er ok at der gøres grin med Cowi og den tilsyneladende ikke særligt vellykkede implementation.

Hvis du ved mere så kom dog ud af skabet!

Jesper Hansen: Man behøver ikke at kende de specifikke detaljer for at kunne se at det her er endnu et offentligt kuldsejlet projekt til alt for mange millioner kr.

Jeg ved hvordan og har lavet løsninger der håndterer 50.000 samtidige brugere med en langt mere kompliceret forretningslogik end submit af nogle spørgsmål fra en test - så svært er det altså ikke at lave noget der kan håndtere små 15.000 samtidige brugere. Slet ikke fordi at der er tale om readonly fælles-data og private write data - det er et optimalt skaleringsscenarie.

Så jo, jeg forbeholder mig retten til at bashe et projekt når der er tale om groft misbrug af offentlige midler og der tilsyneladende bevidst drives gæk med myndighederne - medmindrer der virkelig er tale om et total fravær af kompetancer.

Henrik: Jeg er bestemt ikke mere imponeret efter at have afprøvet systemet - selv spørgsmålene virker ikke specielt gennemtænkte.

Jeg ved hvordan og har lavet løsninger der håndterer 50.000 samtidige brugere med en langt mere kompliceret forretningslogik end submit af nogle spørgsmål fra en test - så svært er det altså ikke at lave noget der kan håndtere små 15.000 samtidige brugere. Slet ikke fordi at der er tale om readonly fælles-data og private write data - det er et optimalt skaleringsscenarie.

Hvis 8 knægte tilbød at lave det samme på 1.5 år og 80 millioner kr, ville de så få lov? Jeg regner med at de skal bruge en 8-16 af de millioner på udstyr, leje af lokaler, mm. De resterende kan så aflønne dem til 8 per person.

Hvis der er udsigt til en sådan løn tror jeg nok jeg vil kunne finde kvalificeret arbejdskraft til at løse problemet.

Indtil der kommer nogen detaljer frem om, hvorfor det her projekt skulle være særligt mere kompliceret end ethvert andet spørgeskema system, synes jeg, at det er helt på plads at "bashe" COWI's "løsning" som komplet inkompetent.

Hvis COWI vil slippe for den dårlige omtale må de ud med nogen detaljer om, hvad det er der er så revolutionerende nyskabende ved det her system, at det kan give de her problemer.

Der bliver ved med at være udtalelser om, at systemet skulle være "den første af sin slags i verdenen". Og umiddelbart virker det eneste unikke ved det til at være den latterligt ringe performance.

Læg mærke til at prøverne er adaptive og altså tager højde for tidligere svar når næste spørgsmål skal findes. Ikke at det på nogen måde kan retfærdiggøre forsinkelser og afbrydelser, men helt off-the-shelf er det altså ikke.

Vi hører kun om offentlige it-systemer der slår fejl - jeg ved ikke om der er nogle systemer der ikke fejler, men det synes at være karakteristisk for dem der gør, at de involverede er ekstremt tilbageholdende med informationer.

Er det ikke muligt at se kravsspecifikationerne og kontrakterne for den slags systemer? Er det bare mig der ikke kan finde dem? Eller regner man den slags for "farlig viden" for den almindelige dansker?

Er der nogen der ved mere, som kan hjælpe med at opklare sagerne?

Kan I få 100% på 3. klasses niveau? Jeg fatter ikke hvordan den kan vurdere det til 97,2% !!!! Prøv lige
http://demo.evaluering.uvm.dk/

Du har ret i, at spørgeskemaet er lidt mere fancy end som så, men det ændrer (som du skriver) ikke voldsomt meget på problemstillingen. Eksempelvis kan man med GWT lave det hele i en JS fil med alle billeder og alt css komprimeret og embedded. Denne fil kan så distribueres lige så tosset man vil, og derefter kan klienten vente med at kontakte serveren igen indtil resultatet skal afleveres. Aflevering af det udfyldte spørgeskema er også muligt trivielt at distribuere til flere servere.

Egentlig burde arkitekturen (og koden) ligge offentligt tilgængeligt, når det nu er os, der er kunderne. Der er trods alt tale om ca. 20 kroner pr. person i Danmark.

Du må ha' misset en trekant :-)

(jeg fik 100%)

Nu må du ikke være så sarkastisk Daniel - det er åbenbart Jesper der har designet systemet. ;-)

Siden Londons børs gik i sort har jeg med jævne mellemrum googlet det. Og aldrig fundet en forklaring. Til gengæld er der ikke mangle på folk uden indsigt der gerne vil udtale sig. Det ville da for helvede være nyttigt, hvis de der viste noget, sagde noget, og de der ikke vidste noget...

Jeg fik heller ikke 100% i mat 3. klasse. Jeg kunne ikke finde ud af det der klik-flyt-klik system når der kun stod "træk". Men efter at have løst nogle andre opgaver hvor der stod "klik-flyt-klik" kan jeg vist godt komme op på 100%. Men der er da forbavsende mange fejl i opgaverne. F.eks skal man finde et synonym for "ydmyg" men der er ingen af ordene som passer. Eller en engelskopgave om to piger og afrika hvor der er to løsninger som passer. Men hvis man vælger den ene, får man fejl. Eller hvad er mest typisk udstyr for en tyv: Bil eller sæk?

Bil eller sæk?

øhhh, pas

hans
msc in civil engineering

@Jesper Hansen
Skru lige ned for gasblusset - vi kan ikke have du skal på sygehuset. Du tager dig selv og det indlæg alt for seriøst.

Vi ved allesammen at situationen hos COWI er mere kompleks end det indlæg udlagde det, men det betyder ikke at man ikke kan gøre grin med det. :) COWI er trods alt i en ualmindelig pinlig situation, som de netop har gjort mere pinlig. Eller mindre pinligt afhængigt af svarene. Derfor frygter vi det værste.

Prøv i øvrigt at lade være med at rase over at vi ingenting ved om systemerne. Det gør du heller ikke, for de har ingenting sagt om det.
Med mindre du er ansat i COWI, naturligvis, i hvilket fald du skulle tage og svare på spørgsmålene i stedet for at komme efter folk med en sans for humor med fråde om munden og røde øjne.

Hvis testen er adaptiv og den nødt til at spørge serveren undervejs, eller kan den jo hackes (derhen at man kan læse i koden hvad der giver et lettere/sværere spørgsmål)

Har hørt fra en pålidelig kilde at fejlen skulle være fundet i en database, der ikke kørte særlig godt.

Det er meget meget nemt at pege fingre ad projekter, der af en eller anden grund slår fejl -- navnligt de offentlige, for der kan alle have en mening -- men det klæder ikke debattørerne at slå over i tyk satire eller personlige angreb: Sandsynligheden for at udviklere bag de problematiske projekter læser disse fora er nær 1, og der er sikkert visse aspekter af projektet, som de er stolte af (sikkert med rette) og måske har de røde ører over andre (måske ikke udviklere, men så sysadmins, DBA'ere, projektledere, whatever) over de ting, der ikke virker.
Men sandsynligheden for at der kommer en frugtbar debat ud af det, evt. med de implicerede, er lig nul hvis kommentarerne ligner YouTubes.

I et miljø af hån og nedsabling er er ingen, der lærer af deres eller andres fejl, pånær hvis de skynder sig at finde nogle større hos sidemanden - og en cadeau til Version2 for at stille spørgsmålene.

[Og nej, jeg er ikke involveret i folkeskolens nationale test]

Kan I få 100% på 3. klasses niveau? Jeg fatter ikke hvordan den kan vurdere det til 97,2% !!!! Prøv lige

77,8%

:-)

Administrator:
".. har trykket på "optimize table" knappen - nu fungerer alt som det skal."

Udvikler:
"Jeg sagde jo, det var godt nok at bruge SQL updates"

:-)

Som en anden skriver er der tale om "private" skrivninger, og følgelig lille/ingen sandsynlighed for låsningsproblemer (jeg antager her at der er tale om en moderne database, der låser på row niveau og ikke på page eller tabelniveau, men som de siger "Assumption is the mother of all fuckups")

@Jesper

Du har ret. Så har man jo valget mellem at gøre en smule køb på sikkerheden under antagelse af, at eleverne ikke har tid til at hacke obfuskeret JS under eksamen, eller lave flere små kald til en distribueret service undervejs.

Under alle omstændigheder ved vi jo ingenting om, hvor problemet ligger, hvilket diskussionen bærer præg af. Jeg håber, at nogle fra Cowi vil komme med flere detaljer, når krisen er drevet over. :)

Der er vel ikke behov for at skrive til databasen overhovedet?

Resultater skal vel bare logges og behandles separat?

Row locks kan eskalere til table locks under de "rigtige" omstændigheder.

"Lock Contention" kan da godt være problemet.
http://www.sql-server-performance.com/articles/per/lock_contention_noloc...

Jesper: Offentligt system eller ej, så er faktum som jeg forstår det at systemet skulle have kørt tilbage i 2007. Fair nok at det ikke lykkedes i første omgang og at man rendte ind i nogle uforudsete problemer - det kan ske for enhver. Men nu taler vi så 2010 og det kører stadig ikke stabilt.

Det er ikke kun et image-problem for COWI det her - det bliver et image-problem for hele branchen når offentlige systemer gang på gang ender i skandaler.

Jeg beklager hvis mit sarkastiske indlæg har stødt nogle COWI-folk. Jeg må indrømme at jeg tænker mest på de stakkels elever der sidder til en for dem vigtig test og oplever systemet bryde ned om ørene på dem og frustrede lærere der står tilbage og skal forklare sig og at de skal igennem den tur hver gang de forsøger sig med en elektronisk løsning.
Derudover kan jeg jo heller ikke lade være med at tænke at 100 mio. kr lyder som en hel del for et sådant system her - vi kan jo alle se slutresultatet på deres demo-side.

Det er muligt at det offentlige ikke selv formår at sige fra, men den var aldrig gået i det private erhvervsliv.

@Daniel: Det er for mig at se et spørgsmål om publikum her - mit gæt er at hovedparten af læserne er folk med fingrene "i sovsen" snarere end at de er blandt de ansvarlige beslutningstagere (belastningstest eller ikke belastningstest)

De 100 mio er nok inklusiv driftsaftalen, som (antageligvis) udgør hovedparten, og (antageligvis) købes for dyrt, bl.a. fordi den (antageligvis) er skaleret efter spidsbelastningen og inkluderer diverse testmiljøer så der (antageligvis) netto står alt for mange servere og snurrer til ingen verdens nytte. (Ja, det er mange antagelser, men det er jo ikke særsyn).

Det er ikke sådan at det private erhvervsliv er fri for fejlinvesteringer, men de er nok meget bedre til at skjule dem, og de er heller ikke underlagt de uheldige udbudsregler og politiske budgetprocedurer, som jeg ser som de største hindring for bedre offentlige IT projekter.

De to sidste spørgsmål kan jeg som lokal it-vejleder på en skole godt svare på:

• Identifikationen sker med for både elever og lærer med UNI-Login. Et login som samtlige elever (på de årgange hvor test afvikles) og lærere (strengt taget kun dem der skal afvikle test, men praktisk talt alle lærere har i årevist haft det) skal havde. Login er paret op på deres cpr-nummer.
  UNI-Login anvendes i dag i folkeskolen til en lang række ting, lige fra adgang til data hos eksterne leverandører (forlag mm), ansøgning om optagelse på ungdomsuddannelserne på optagelse.dk til mail på SkoleKom mm. Mange skoler bruger det også som login til deres lokale AD ved hjælp af et synkroniseringsværktøj.
  Har en elev på testdagen glemt enten brugernavn eller pw til sit UNI-Login kan læreren laver et midlertidig login til testen på ca. 30 sekunder til eleven.

• Krav til de lokale skolers netværk kan ses i vejledningen der er findes på:

http://support.emu.dk/evalportal/vejledninger/DNT-vejl-forberedelse-v2.p...

under antagelse af, at eleverne ikke har tid til at hacke obfuskeret JS under eksamen

Hvis de har haft tid til det, har de sku' fortjent at få 100% rigtige :)

Ifølge http://evaluering.uvm.dk/BinaryContentProvider?binaryId=2871 er nogle af kravene til systemet, at det skal kunne håndtere:

• 6000 samtidige brugere.
• 99.8 % oppetid og maximalt 3 sekunders svartid.

Desuden kræver den adaptive tilgangsvinkel over 500 opgaver pr. test som alle er testet af ca. 700 elever.

Hvordan er front-end-designet – ligger testen fx i Ajax eller lignende, eller skal der kommunikeres frem og tilbage for hvert spørgsmål?

Nu kommunikerer AJAX (og lign.) altså også frem og tilbage. Måske ikke for hvert spørgsmål i dette tilfælde, men det ville være smartest iforhold til ikke at miste brugerens indtastede data i tilfælde af browser/pc/internet/server fejl.

Hvis man har anlagt en (som jeg kalder det) "desktop approach", så vil man i allerhøjeste grad opleve låsningsproblemer - også ved samtidige "select..."

I en webapplikation ville man dog ALDRIG låse på tværs af requests og i stedet bruge optimistisk låsning hvis det overhovedet er nødvendigt. En spørgeskemaundersøgelse som denne kan løses med inserts der er helt uafhængige. Og da hele spørgsmålsbasen er read-only under testen kan man cache det hele (med fordel). Så systemet kan sagtens skrues fornuftigt sammen uden låsningsproblemer.

Men vi kommer begge to med gæt på hvad problemet er eller ikke er, uden at vi aner noget hvordan det i virkeligheden er skruet sammen.

Angående London børs:

http://www.popsci.com/technology/article/2010-01/rogue-algorithm-threate...

Ved ikke rigtig om jeg vil tro den forklaring. The computer did it!

Jeg tager udgangspunkt i, at det er .NET drevet, og på samme måde som java, har disse ting det med at udvise eksponentielt stigende 'svartider', for til sidst at brække sig.

Et typisk opførsel hvis der er memory leaks i programmet. Jeg har programmeret en del i både C++ og Java og i begge kan man have memory leaks, hvis man ikke passer på.
Java har en maxgrænse for hvor meget RAM den må bruge og når den grænse er nået går programmet i knæ. Typisk med et meget højt forbrug af CPU pga at GC så kører uafbrudt.
Et C++ program har typisk ikke nogen max RAM-grænse, så det begynder at swappe til disken og får alle andre programmer på maskinen til også at swappe, så her går CPU ikke i max, men alt går i stå alligevel.
Men det er jo ikke vildt svært at teste om et program har en væsentlig memory leak, så jeg tvivler på at det er årsagen.

Jeg regner med at de skal bruge en 8-16 af de millioner på udstyr, leje af lokaler, mm.

det kan købes meget billigere hos Amazon AWS.

Jeg arbejdede engang i en virksomhed hvor .NET arkitekterne fortalte vores kunder m. fl. at static var sessions-variable i .NET.

Er der nogen der kan forestille sig, hvorfor det system de lavede ikke virkede særlig godt?

Det er svært at gardere sig imod sådanne tåbeligheder.

Det med at checke GC mv. er under profiling, det gør vi for at finde memory leaks. Høj GC aktivitet vidner typisk om potentielle memory leaks, men kan også skyldes et meget højt object churn.

Performance analyser skal laves udefra og ind, det er tit der fejlene opstår, fordi der med det sammefokuseres på profilering mv.

Der findes udemærkede GC libraries til C++. F.eks. .NET (managed C++).

GC er dog så forskelligt, og har udviklet sig så meget, at det ikke behøver være et problem.

Hvad er det der adskiller dette system fra systemer der anvender proces-/regel motorer?

GC'en er sjældent et problem idag, men der er situationer i specielt højbelastnings-scenarier hvor man skal vide lidt om hvordan den fungerer for at kunne optimere til den.

Jeg tvivler også på at det som sådan var GC'en der var problemet i Stig Johansen eksempel, for 10 requests/sec er meget lidt.

Jeg har lavet systemer der i stresstests håndterede 4000 requests/sec i .NET - og ja, vi oplevede små periodiske udfald hvor antallet dykkede grundet GC collects, men her taler vi så også langt mere end 10 requets/sec og det var typisk udfald af 100-200ms varighed (I nogle systemer måske et acceptabelt udfald). Ved at optimere allokeringen og bruge object-pooling var det også muligt at fjerne disse udfald.

Så hvis man ved hvad man laver er GC'en ikke nogen begræsning i forhold til at lave high-throughput løsninger og fordelene ved at anvende C# og .NET gør det nemt ud for den smule GC-optimering man skal være opmærksom på.

Skalering til den mængde brugere, om de så alle sad og lavede requests på samme tid, skal altså kunne laves for 80-100 mio.

36.000 objecter i timen er nix og nada at håndtere for GC'en, medmindrer objekterne er så store at de allokeres på Large Object Heapen så kan det godt give problemer (kræver at objekterne er >58k bytes).

Det omtalte system som vi stresstesdede er en Comet-baseret HTTP-server, til at lave realtime push ud til browser-klienter - det er hovedsageligt en løsning der henvender sig til realtime multiplayer browser-spil. Der er dog tale om en properitær løsning, så jeg kan desværre ikke rigtig vise det i praksis endnu.