Kender du Danmarks bedste it-arbejdsplads?
Vær med til at udpege den bedste blandt nogle af Danmarks største it-virksomheder og it-arbejdspladser og deltag i konkurrencen om et rejsegavekort á 5.000 kr. og fem gavekort à 500 kr.
Nykredit
KMD
Swarco Technology ApS
Saxo Bank A/S
NK-Forsyning A/S
Mercuri Urval A/S
Faxe Service A/S
Babcock og Wilcox Vølund A/S
Afstemning
NemID har nu været i brug i to måneder. Har du fået en NemID?
Test-skandalen: Her er spørgsmålene Cowi ikke vil svare på
Cowi afviser at besvare en række tekniske spørgsmål, der kunne give offentligheden en bedre forståelse for, hvorfor der nu er massive problemer med folkeskolens nationale test. Nye oplysninger tyder på, at problemet er større end først antaget.
Cowi, der er leverandør til det skandaleramte it-system til folkeskolens nationale test, vender nu rundt på en tallerken og ønsker ikke at besvare en række spørgsmål om de tekniske forhold.
Version2 sendte i går en mail med de mere tekniske spørgsmål til Cowi-direktør Knud Erik Christensen og aftalte, at han eller en relevant, teknisk kyndig person ville besvare dem snarest muligt.
I dag meddeler Knud Erik Christensen imidlertid, at løsningen af problemet kommer i første række, og at Cowi derfor ikke har ressourcer til at besvare spørgsmålene.
Version2 har derfor valgt at offentliggøre de spørgsmål, som Cowi ikke ønsker at besvare
- Hvilken hardware kører systemet på?
- Hvilke muligheder er der for at skalere løsningen?
- Hvem hoster løsningen?
- Hvordan er løsningen belastningstestet?
- Hvor stor en belastning er systemet designet til?
- Skyldes fejlen i det hele taget overbelastning?
- Hvordan kunne tilmeldingen til Folkeskolens Afgangsprøve være under mistanke for at influere på performance i de nationale test?
- Er ovennævnte nu ’frikendt’?
- Hvordan er front-end-designet – ligger testen fx i Ajax eller lignende, eller skal der kommunikeres frem og tilbage for hvert spørgsmål?
- Hvordan identificeres de enkelte elever?
- Hvilke krav stiller løsningen til de enkelte skolers netværk
Knud Erik Christensen vil heller ikke forholde sig til nye oplysninger fra Politiken, der i en reportage i dagens udgave beretter om elever, der har fået stillet samme spørgsmål tre gange. Hvis denne oplysning passer, er der således ikke længere ’blot’ tale om lange svartider og kapacitetsproblemer, men en designfejl i selve udformningen af løsningen.
Ifølge Version2’s oplysninger kan der dog muligvis være tale om, at mange af spørgsmålene i opgavesættende minder meget om hinanden, og at svartids-stressede elever ikke nødvendigvis opfatter små ændringer i spørgsmålenes formulering.
Version2 sendte i går en mail med de mere tekniske spørgsmål til Cowi-direktør Knud Erik Christensen og aftalte, at han eller en relevant, teknisk kyndig person ville besvare dem snarest muligt.
I dag meddeler Knud Erik Christensen imidlertid, at løsningen af problemet kommer i første række, og at Cowi derfor ikke har ressourcer til at besvare spørgsmålene.
Version2 har derfor valgt at offentliggøre de spørgsmål, som Cowi ikke ønsker at besvare
- Hvilken hardware kører systemet på?
- Hvilke muligheder er der for at skalere løsningen?
- Hvem hoster løsningen?
- Hvordan er løsningen belastningstestet?
- Hvor stor en belastning er systemet designet til?
- Skyldes fejlen i det hele taget overbelastning?
- Hvordan kunne tilmeldingen til Folkeskolens Afgangsprøve være under mistanke for at influere på performance i de nationale test?
- Er ovennævnte nu ’frikendt’?
- Hvordan er front-end-designet – ligger testen fx i Ajax eller lignende, eller skal der kommunikeres frem og tilbage for hvert spørgsmål?
- Hvordan identificeres de enkelte elever?
- Hvilke krav stiller løsningen til de enkelte skolers netværk
Knud Erik Christensen vil heller ikke forholde sig til nye oplysninger fra Politiken, der i en reportage i dagens udgave beretter om elever, der har fået stillet samme spørgsmål tre gange. Hvis denne oplysning passer, er der således ikke længere ’blot’ tale om lange svartider og kapacitetsproblemer, men en designfejl i selve udformningen af løsningen.
Ifølge Version2’s oplysninger kan der dog muligvis være tale om, at mange af spørgsmålene i opgavesættende minder meget om hinanden, og at svartids-stressede elever ikke nødvendigvis opfatter små ændringer i spørgsmålenes formulering.
- Ekspert: Kun en fyring af Cowi kunne forhindre test-skandalen (4/3 2010)
- Cowi stadig blanke: Der går dage, før nationale test er klar igen (4/3 2010)
- Minister erkender, at skole-test har spillet fallit: Gør testning frivillig (3/3 2010)
- Cowi: Vi aner ikke hvor fejlen er (2/3 2010)
- Nationale elevtest brudt ned igen: Cowi undersøger lange svartider (2/3 2010)
- 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
- ?
- ?
- 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
- ?
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
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.
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.
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.
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!
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.
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.
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?
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/
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.
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.
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?
@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.
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]
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"
:-)
".. har trykket på "optimize table" knappen - nu fungerer alt som det skal."
Udvikler:
"Jeg sagde jo, det var godt nok at bruge SQL updates"
:-)
Det undrer mig, at der ikke spørges til databaserne, og hvilken tilgang der er brugt.
Jeg har set masser af eksempler i nyhedsgrupperne, hvor man - rent ud sagt - 'misbruger' databasen.
Netop den tilgangsvinkel vil med meget stor sandsynlighed føre til performanceproblemer i flerbrugersystemer.
Jeg taler ikke om hastigheden som sådan, men låsningsproblematikker.
Hvis det er årsagen, skal de nok rette en hel del for at få det til at køre.
Jeg har set masser af eksempler i nyhedsgrupperne, hvor man - rent ud sagt - 'misbruger' databasen.
Netop den tilgangsvinkel vil med meget stor sandsynlighed føre til performanceproblemer i flerbrugersystemer.
Jeg taler ikke om hastigheden som sådan, men låsningsproblematikker.
Hvis det er årsagen, skal de nok rette en hel del for at få det til at køre.
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. :)
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.c...
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.c...
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.
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 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/ve...
- 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/ve...
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/BinaryCont... 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.
* 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.
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")
Du laver en forkert antagelse.
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..."
Jeg ved ikke lige hvad man ska søge efter, men "aggresive locking scheme" burde være et godt bud.
(har kodet kritiske flerbrugersystemer i knap 30 år, så har ikke lige behov for at søge;)
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/ar...
Ved ikke rigtig om jeg vil tro den forklaring. The computer did it!
http://www.popsci.com/technology/ar...
Ved ikke rigtig om jeg vil tro den forklaring. The computer did it!
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.
Jeg er enig i, at hverken jeg eller du ved hvordan det er skruet sammen.
Eller mig i hvertfald, så mit indlæg skulle ikke betragtes som et 'gæt', nærmere at det virker som en typisk 'stinker'.
Mit indlæg skulle læses som et hint til Cowi, i forhold til hvor de burde koncentrere analyse af fejl - da de (jfr. V2 ikke selv kan finde ud af det).
Et andet hint, er at fokusere på GC.
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.
Men som sagt vil jeg ikke kloge mig på løsningen, da jeg ikke kdender den, men kun give et par hints om hvor flaskehalsen befinder sig.
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.
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.
Næh det er måske ikke så svært, men man skriver at Cowi ikke kan finde fejlen, ej heller kan stressteste.
Mht .NET behøver er ikke være tale om memory leaks, da GC'en skal rydde op efter alle requests.
Jeg stod for driftsprøve af ISB'en engang, og allerede ved 10 req/sekund var den tæt på at gå i knæ.
(Testede ikke hårdere belastninger, da det var kontraktuelt fastsat)
Hvis man plotter svartiderne ind i noget SVG, kan man tydeligt se 'behaviour':
http://w-o-p-r.dk/svg/burst.2003011...
(Kan sikker ikke ses i IE, så brug f.eks. Opera).
Som sagt er det kun et par hints til Cowi om hvor de kan søge efter flaskehalsene, som typisk er DB/GC.
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.
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å.
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.
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.
Har du regnet lidt på det?
10 req/sekund giver immervæk 36.000 req/time.
Når du skriver 4000 req/sek, så giver det 14.400.000 req/time, eller 115.200.000 req/dag (8 timer).
Har du noget imod at uddybe hvilket system, der modtager disse mange requests ?
(jeg snakker om sustained rate, ikke peak rate).
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.
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.
14- 3 minutter siden - Pas på: Er din virksomhed ramt af superlusket rootkit? (12)
- 33 minutter siden - Nykredits tilbud: Log på netbank med NemID - uden papkort (22)
- 1 time siden - Microsoft i Vedbæk: Homoseksuelle gør virksomheder mere kreative (3)
- 3 timer siden - Hvem har hacket DI ? (3)
- 6 timer siden - Dorte Toft om 17-årigs NemID-kvaler: Vi har brug for en ID-ombudsmand (9)
- 8 timer siden - Googles frontalangreb på Skype: Ring gratis fra din Gmail (47)
- 9 timer siden - Se videoen: Lady Java lokker norske udviklere til konference (2)
- 10 timer siden - Anonyme tip til kommunen: Brug telefonen i stedet for e-mail (6)
- 10 timer siden - DanID afviser password-kritik: Ligegyldigt at skelne mellem store og små tegn (81)
- 10 timer siden - KL: Digital borgerservice er god borgerservice (2)
Relaterede emner
Redaktionen anbefaler
