Derfor kiksede Polsag: Krævede 100.000 SQL-kald i sekundet

7,8 millioner http-requests i timen og svimlende 100.000 SQL-kald i sekundet til en enorm Oracle-installation. Ny kritik fra statsrevisorerne af politiets it-system Polsag sætter igen fokus på CSC-systemets elendigheder.

Den store it-skandale om Polsag-systemet, som skulle danne basis for en omfattende it-modernisering hos Politiet, er nu officielt et overstået kapitel, efter at statsrevisorerne meget usædvanligt valgte at gentage kritikken af hele forløbet i denne uge.

Læs også: Statsrevisorer gentager svidende Polsag-lussing: "Uprofessionel og utilfredsstillende"

Dermed er myndighedernes selvransagelse slut, og Rigsrevisionens beretning fra foråret 2013 får lov at stå for eftertiden. En rapport, der giver et overblik over de mange svigt og fejl, som skete undervejs, både hos Rigspolitiet og hos leverandøren CSC, som brugte Scanjour som underleverandør.

I rapporten bliver de tekniske problemer også hevet frem, og et af de store kritikpunkter fra de 80 bornholmske betjente, der som de eneste fik brugt Polsag i praksis, var lange svartider. Den lille politikreds på Bornholm kørte nemlig Polsag i pilotdrift i over et år, og de meget dårlige erfaringer herfra var en af grundene til, at projektet blev lukket helt ned i februar 2012.

Læs også: Derfor blev Polsag skrottet: Ville koste 1,4 milliarder kroner

Det eksterne tekniske gennemsyn af Polsag fra konsulentfirmaet Globeteam viser, hvorfor der var performanceproblemer. Et skøn viste, at webserverne i systemet en mandag formiddag rutinemæssigt ville blive udsat for 7,8 millioner http-request. Det ville kræve 44 servere, men testen gik kun på 13 udvalgte handlinger i Polsag-systemet og tog ikke højde for andre operationer eller spidsbelastninger. Tallet kunne derfor være meget højere i praksis.

Men selv med det lave, skønnede tal, ville det sætte Oracle-databasen, der var kernen i Polsag-systemet, under massivt pres. Databasen ville få 100.000 SQL-kald i sekundet, og det ville kræve en Oracle-server med mellem 60 og 128 processorer at drive. Oven i ville så komme logning, der omtrent ville fordoble antallet af kald til databasen - igen blot med de 13 udvalgte handlinger - så hardwarekravene ville i praksis være helt overvældende.

»Dette er et virkeligt stort tal, nærmest uanset hvor stor en Oracle-installation, der er tale om,« lyder vurderingen i den eksterne rapport.

Også den it-ekspert, som Rigsrevisionen har brugt, er lamslået.

»Set med teknikerens øjne er det stort set umuligt at håndtere så stort et antal,« skriver Rigsrevisionen.

I forhold til den server-kapacitet, som var planlagt til Polsag-systemet, var der brug for en massiv opgradering, hvis ikke svartiderne skulle være urimeligt lange. Det ville både koste i mere hardware, flere licensomkostninger til Oracle og højere driftsomkostninger hos CSC.

Læs også: Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode

Undersøgelserne blev i øvrigt foretaget på Polsags uddannelsesmiljø, og ikke test- eller produktionsmiljøet, som konsulenterne ikke havde adgang til. Det gør det svært at vurdere helt præcist, hvor galt det stod til, og ifølge Rigsrevisionen blev der senere hen gennemført nogle test i produktionsmiljøet, som viste forbedringer.

Men forbedringerne var altså ikke overbevisende nok til, at man valgte at prøve at redde Polsag-systemet. I stedet blev det lukket helt ned i februar 2012, og 567 millioner kroner var med ét slag spildt. Leverandøren CSC havde systemet i pilotdrift på Bornholm fra december 2010 og frem til lukningen, men her blev altså heller ikke vist gode nok fremskridt undervejs.

Konsulenterne fra Globeteam havde en del forslag til, hvordan ydelsen kunne blive forbedret. Det omfattende blandt andet at få caching til at virke i browseren, og udvide den fra 24 timer til flere dage. Dermed ville mængden af data, der skulle overføres, når en betjent åbnede forsiden i Polsag-systemet, gå fra 5,5 megabyte til 2 megabyte.

Læs rapporten fra Globeteam med de tekniske detaljer (antallet af databasekald bliver beskrevet på side 10 og frem):

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (106)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Nørregaard Blogger

Det er helt astronomiske tal, som kommer frem her.

På datalogistudiet blev flere af os overraskede over at man i databasedesign ikke går efter 4 eller 5. normalform når det nu var det smukkeste men i stedet nøjedes med 3. eller endda 2. normalform. Men sådan er virkeligheden: Man skal gå på kompromis mellem smuk arkitektur og performance, også her 20 år senere.

POLSAG lader til, alene baseret ud fra de tal, at være overarkitektet (over-SOA'et?) uden sans for realiteternes hårde vilkår. Ud fra et fagligt synspunkt er det interessant at finde ud af hvem som dog er ansvarlig for dén model. Og mere interessant:
- Hvor ligger tilsvarende skandaler og venter på at eksploerer i mødet med virkeligheden?
- Og hvordan undgås tilsvarende fejltagelser fremover?

  • 16
  • 0
Poul-Henning Kamp Blogger

Der er 10400 politifolk i Danmark.

7.8 mio HTTP requests/time er derfor 750 per betjent per time.

7.8 mio HTTP requests på en time er 2166 i sekundet.

2166 req/s fordelt på 44 servere = 49 req/s per server.

Med 100.000 databaseopslag/sek laver hver HTTP request ca. 46 database opslag.

Forsiden kræver 5.5 MB overføres til browseren ?

Der er ingen måde I kan overbevise mig om at der har været en kompetent arkitekt på den opgave.

Vi skal have en IT havarikommision NU!

  • 58
  • 0
Oscar Gensmann

Hvis de kan få en forside på et administrativt system op på 5,5MB.

Hvis man har brug for at få en fornemmelse af hvad man dog kunne have spyttet ud på 5,5MB til en forside, så fylder politiken.dk ca 3MB og bt.dk 3,7MB (med reklamer)....

At man først i sidste konsulentrapport over "hvad gik galt" overvejer at "få cachen i browseren til at virke", er simpelthen så mageløs skræmmende, at man får lyst til at kræve at samtlige offentlige IT-projekter nogensinde leveret af CSC gåes igennem for hvad man i bedste fald kan kalde begynderfejl og i værste fald kaldes "pengeafpresning for at hæve prisen på driftsbudgettet".

PHK: Blev systemet ikke kun brugt af 80 betjente? (Hvilket kun gør det endnu mere skræmmende)

  • 19
  • 0
Poul-Henning Kamp Blogger

få cachen i browseren til at virke

Lige nøjagtig den detalje vil jeg være varsom med at fordømme: Det skal være absolut sikkert at der ikke gemmes fortrolige data i browser (og andre..) caches.

Ikke mindst af hensyn til loggning af adgang til fortrolige data.

MEN, det betyder bare at man skal tænke sig en smule mere om, ikke at man slet ikke kan bruge cachen.

I særdeleshed kan man sagtens bruge server-side caching som f.eks Varnish af de fortrolige data, hvis bare man sørger for at inddrage logfilerne derfra i rapporteringen.

  • 8
  • 0
Mikkel Lauritsen

Uintelligente ORM'er

Mjaeh; måske snarere udviklere, som ikke er klar over, hvordan et ORM-lag fungerer.

Nu ved jeg ikke hvilken platform POLSAG er lavet på, men når man ORM'er en relationel datamodel op mod en objektgraf ender man ofte grundet lazy loading med at få et databaseroundtrip pr. objektreference som man traverserer. Hent en collection med 20 elementer, iterer gennem den og tilgå to objektreferencer pr. element - resultat: 41 roundtrips. Mindst.

Det kan man komme udenom, men det kræver, at man er klar over problemet.

  • 4
  • 0
Poul-Henning Kamp Blogger

Hvis vi havde haft en IT-Havarikommision, havde de helt sikkert også interesseret sig for om designet blev påvirket af kontraktens betalingsform.

Hvis der f.eks er en volumenbaseret eller ligefrem "Click" baseret komponent i driftsudgiften, giver ovenstående tal jo eminent god mening.

  • 8
  • 0
Jens Beltofte

Lige nøjagtig den detalje vil jeg være varsom med at fordømme: Det skal være absolut sikkert at der ikke gemmes fortrolige data i browser (og andre..) caches.

Men hvis forsiden fylder over 5MB må man gå ud fra at der slet ikke gemmes noget i browserens cache. Man kunne starte med at gemme alle billeder, CSS og JavaScript filer i cachen - det kan ikke være fortrolige data ;-) Og så nøjes med at lade HTML-outputtet blive genereret hver gang eller lade Varnish cache den del.

  • 1
  • 0
Kai Birger Nielsen

> Det kan man komme udenom, men det kræver, at man er klar over problemet.

Det er jo det næste sindsyge ved det her projekt. Hvor lang tid kan det lige tage at lave en mockup af modellen og se om performance er helt fin eller en by i Rusland?
I stedet lyder det jo til at de har kodet det hele og så først bagefter opdaget at skræmmende lange svartider ikke gik væk af at man koblede flere brugere på.

  • 4
  • 0
Oscar Gensmann

PHK: Jeg havde ikke umiddelbart i min vildeste fantasi forestillet migat det kunne være fortrolige data de havde tænkt sig at gemme i en client side cache (derfor jeg ikke lige tog forbeholdet, men du har ret).

Jeg læser det ret meget som at de par MB de kunne skære af, formodentlig er statiske filer som CSS og Javascript, og billeder. Det er i hvert tilfælde min erfaring når jeg har været kaldt ind over håbløse projekter der er blevet for store.

  • 3
  • 0
Poul-Henning Kamp Blogger

Men hvis forsiden fylder over 5MB [...]

Ved vi faktisk ikke hvad der står på den.

Det kan faktisk være at selve bruger-designet er intelligent, således af forsiden består af aktuelle data, omhyggeligt tilpasset den enkelte betjent, med summary af hændelser i verserende sager osv. osv.

Det burde den ihvertfald.

Omvendt kan det naturligvis sagtens være at alle betjente mødes med et 1000px ucachet billede af deres nærmeste foresatte og strategien for korpsånden i server-renderet form, for at få fontene til at passe med designmanualen.

Men overordnet set: 5.5 MB er næppe opstået fordi nogen har kigget på hvor meget information reddit.com presser ind i 110-120KB.

  • 8
  • 0
Claus Jacobsen

man kunne jo starte med at cache den grafiske brugerflade som jo ikke indeholder følsomme data - men en brugerflade på 5,5mb lugter sg meget af at der er brugt bitmap billeder lavet i MS paint. Jeg ville umiddelbart tro at det ville kunne fjerne omkring 4/5 af de 5,5mb uden at have set det. 1,1MB ren data indeholder nu alligevel en del tegn - i det hele taget brug af AJAX teknologier eller ligenende ville da helt klart være et krav med mindre det har været nogle ualmindeligt svagtseende programmører/ledere hos CSC der har været involveret.
Havde engang fornøjelsen af at snakke med en Business developer omkring et projekt til en E-shop af pæn stor størrelse, om hvorfor i al vide verden der ikke blev brugt noget caching af grafik, AJAX-teknologier eller lignende. - Svaret var bare at der i sandhed ikke blev brugt BETA-teknologi i produktion. - så måtte jeg jo spørge ham om hvor længe GMAIL havde været i Beta - sjovt nok ingen svar, men senere blev der godt nok iværksat en større undersøgelse af hastighederne på projektet ude hos nogle kunder :D

  • 3
  • 1
Oscar Gensmann

PHK: "Ved vi faktisk ikke hvad der står på den."

Det er korrekt, men ud fra normale gængse arbejdsmetoder, må man også kunne forvente at hvis en leverandør oplever virkelige lange svartider på en forside og de virkelig ikke har en masse ligegyldige ting på den, at man så ville tage fat i en anden UX model eller lignende for at præsentere informationerne lazy eller lignende.

Jeg kan ikke i min vildeste fantasi forestille mig et scenario til en forside af et sagssystem der kræver præsentation af 5,5 mb data, som ikke kunne fordeles UI-mæssigt over flere requests således at de gange man bare skal ind på en forside for at komme hurtigt videre, så slap systemet for at loade 3 års kalenderdata med samtlige betjente i danmarks fødselsdatoer eller lignende "nice to have" forside/dashboard ting.

Mit bedste bud er at der har været bevismaterialebilleder i highres retina opløsning fra de seneste 10 sager, samt "most wanted" information og billeder af de eftersøge i en flot flot roterende flash kube, så der også var lidt spændende at kigge på....

  • 4
  • 1
Claus Jacobsen

Helt korrekt - det ville jo i den grad være oplagt at lave et setup med integration af lidt ala http://www.q-inspect.com/

Så er det frisk i hukommelsen, og de ville ikke skulle bruge nær så meget tid på at skulle sidde til kl lort om aftenen for at afrapportere.

MEn nu går der jo så heldigvis lang tid før det sker, så sikringsbranchen får endnu mere kronede dage når tyvene er på facebook, og ellers bruger de moderne teknologier i MEGET stor udstrækning. Det er jo betryggende at vide at politiet så sidder på deres pandekage på kontoret fordi de skal sidde og tampe en masse bogstaver ind i et system hvor man skal vente mellem hvert bogstav.

  • 0
  • 0
Jesper Kildebogaard

Jeg tror ikke, der på nogen måde var tale om smart integration med andre tjenester og et fint 'business intelligence'-overblik for hver betjent.

Polsag-systemet var nemlig tænkt som en mere teknologisk moderne videreførelse af det nuværende Polsas (fra 1997), så kravet var faktisk, at det lignede det gamle, hvilket også i sig selv gjorde, at Scanjours Captia-system skulle tilpasses endnu mere.

Hele Polsag-projektet blev kaldt et 'infrastruktur-projekt', altså en mere moderne teknologisk platform, som Politiet og andre dele af retssystemet så efterfølgende kunne bygge videre på med smarte integrationer og tjenester.

Og tanken om mobil-tilpasning har helt sikkert ikke været på plakaten tilbage i 2005-2006, da Politiet skulle formulere kravene til Polsag...

vh.

Jesper, Version2

  • 7
  • 0
Jesper Kildebogaard

Så det vi reelt kigger på er noget i stil med det screenshot der er på:

http://www.scanjour.dk/en-GB/ECM-products/Products-for-the-public-sector...

Det ville være i den moderne ende - hvis Polsag faktisk blev designet til at ligne det gamle Polsas, er det noget med en blå skærm og IBM 3270-terminal-stemning.

Jeg kom i tanke om et anden Polsag-tal: Da systemet gik i pilotdrift på Bornholm, krævede det 7.000 datatræk, når en betjent bad om at se døgnrapporten. Det fik CSC dog bragt ned.

  • 5
  • 0
Oscar Gensmann

Jesper: Det ville være i den moderne ende - hvis Polsag faktisk blev designet til at ligne det gamle Polsas, er det noget med en blå skærm og IBM 3270-terminal-stemning.

hehe ok. Kunne være sjovt at se et skærmbillede af det.

Men netop fordi det som udgangspunkt er fra et "moderne" system som det de viser på scanjour-siden, kunne man godt friste til at forestille sig at de har "tilpasset" det ved at smide en masse ekstra css ovenpå der "nulstillede" de fine ting, men fordi det er en tilpasning så har de ikke kunne smide diverse orginale css-ting ud og også behold diverse js-libs.

Så på den måde kan en simplificering sagtens have vokset siden i stedet for at mindske den.

  • 1
  • 1
Claus Jepsen

@Jesper:
"Polsag-systemet var nemlig tænkt som en mere teknologisk moderne videreførelse af det nuværende Polsas (fra 1997), så kravet var faktisk, at det lignede det gamle, hvilket også i sig selv gjorde, at Scanjours Captia-system skulle tilpasses endnu mere."

Det er præcis problemet. Politikerne fik vedtaget at offentlige sagssystemer skulle være blandt de ESDH systemer der var shortlistet til udbud. Det er aldrig en god start at vælge system inden behov kendes, og derfor smadrer man et velfungerende standardsystem totalt, ved at få det til at ligne noget andet.

  • 4
  • 0
Piotr Czarny

Der er nok tale om både ORM'e og et lag af webservices (sandsynligvis .net), som bliver brugt til at rendere UI.

Nogle frameworks gør en dyd ud af, at det skal være lige så nemt at kalde metoder via SOAP, som det er at kalde lokale metoder. Når man så vælger at gøre det, får man hurtigt problemer.

F.eks: vis liste over sager

sager[50] = hent50NyesteSager();
foreach( sag in sager)
hentDetaljerForSagen(sag);

Vær så god. 51 HTTP requests og gud-ved-hvor-mange SQL queries på 3 linjer kode, som ser meget meget harmløse ud.

  • 15
  • 1
Kristian Sørensen

Bare til sammenligning så oplyser VISA at de behandler 179 millioner transaktioner pr. døgn ved spidsbelastninger på verdensplan. Det 2100 pr sekund.

Det er transaktioner som i "en person kører hæver kontanter på sit visakort".

Gad vide hvor mange sql kald de udfører pr. transaktion? De skal bruge 50 for at nå op på polsag niveau ;-)

http://corporate.visa.com/newsroom/press-releases/press604.jsp

  • 9
  • 1
Claus Jacobsen

Helt sikkert - og set ud fra et hardwaremæssigt synspunkt ville jeg også være skræmt fra vid og sans hvis jeg havde skullet skalere HW til en løsning med de krav dengang. (05-06) Der fandtes kun 1 måde at skalere på - flere diske, og det ville helt sikkert dræbe enhver økonomiansvarlig hvis jeg var kommet med en pris på den løsning (servere, men i højere grad storage, da det jo i virkeligheden er dem der skal give IOPS til alle requests.)

I dag ville være en helt anden sag, men Globeteam skriver faktisk noget meget vigtigt i deres evaluering. - De nævner ordet datawarehousing - og det var selvfølgelig ikke fremme overhovedet på x86 niveau tilbage i 06, det var kun i mainframe/HPC verdenen. Men det der slår mig er når man læser eval, at de overhovedet ikke har tænkt sig ret meget om! - Måden man har tænkt på afsløres i høj grad i den måde de vælger at definere "skaleringer" som værende en "simpel server" der kan køre en hel politikreds, og man har x antal kredse, ergo skal man dimensionere x antal servere. Problemet er jo så bare desværre at de ikke har lavet nogle skaleringer, men derimod "genbrugt" gammelt udstyr, endsige forsøgt at skalere HW efter SW-kravene(selvfølgelig meget svære på kravspec stadie, men i testfase burde man nu alligevel have nogle præliminære målinger på IOPS der kan bruges til at skalere efter, og allerede her burde programmører kunne ane uråd hvis de pludselig kræver 1mio iops i testfasen! :-D ) og regnede med at det nok skal køre. Det er en sikker opskrift på katastrofe at man ikke har nogen som helst synergier mellem HW og SW (hvor grelle SW-kravene så end er.) men bare har brugt nogle antagelser om at sådan kørte det gamle system, så må det nye også kunne køre sådan. (men det er jo netop hele ideen med at udskifte :D - at den underliggende teknologi skulle skiftes, men se ud som før)

I mit tidligere indlæg skrev jeg om ajax og caching. Jeg er godt klar over at disse ting overhovedet ikke var vildt fremme tilbage i 06, men de har så ikke engang fulgt best-practice for design af UI som stadig fandtes dengang. Det var jo lige i starten af Xhtml's indtog i webbranchen og dengang var de fleste større danske CMS'er allerede klar med Xhtml strukturer, xslt, xml-quiries (frontpage anyone?) så det er i høj grad nogle projektledere der i den grad hellere må undlade at skrive det på deres CV - hvis jeg stod som rekrutteringsperson, ville de aldrig kunne få et job indenfor branchen igen.

  • 0
  • 0
Lars Bjerregaard
  • 2
  • 0
Jesper Louis Andersen

Nogen gange tænker folk bare at ineffektivitet kan skaleres med at kaste nok hardware efter problemet. Ideen er at man bare kan købe en større maskine og så få tingene ordnet på den måde. Det er så billigere end at udvikle tingene ordentligt, fordi omkostningen til den større hardware kun skal betales en gang eller lignende.

F.eks. er forbløffende mange Ruby-installationer single-process med en enkelt tråd. Det gør at du skal køre en 50-100 Ruby processer per maskine for at udnytte den og har en million swtch'es. Men du kan så omgå det ved at kaste 30 c1.xlarge instanser efter det hos Amazon. At du så kunne klare dig med 3 maskiner hvis det var skrevet i Go eller lignende er der ikke nogen der interesserer sig for.

Det kunne tænkes at det var den samme ide her. Man troede man bare kunne skalere hardwaren senere. Og så fik man designet sig en arkitektur der aldrig nogen sinde vil flyve. 100K TPS lyder ikke af specielt meget i min verden, men set i forhold at det er Oracle-backed og at du på ingen måde har behov for den query-frekvens, så er der noget galt.

For mig at se er det noget der skal kunne klares med en Standard OLTP-database uden nogen problemer overhovedet. Og hvis transaktion-count går over 100 per sekund, så er der noget seriøst galt. Det er mennesker, et begrænset antal, der skal bruge det her system.

  • 3
  • 0
Claus Jacobsen

@PHK jeg sagde ikke at det ikke var eksisterende! :D Men en virksomhed som CSC der under ingen omstændigheder er i stand til at bryde ud af en standardiseret verden baseret på gamle og ekstremt gennemprøvede ting (jeg vil æde min hat på at de fleste brugte algoritmer i polsag er copy paste fra alle mulige andre små projekter de har haft, og det virkede der - så må det også kunne bruges her) Så er jeg sikker på at man kun brugte ting der var "fremme hos Gartner".

Det er desværre ofte sådan meget store virksomheder opfører sig. - De stopper med at tænke selv, bygger en forretning på noget velkendt som "eksperter"/analysebureauer siger er hot, som de kan malke kunderne på, og tænker ikke over næste skridt - det får de ikke penge for. Det er nøjagtig den samme årsag til hvorfor MS ikke er stand til at vinde folk med Win8 (w8p). Deres mantra er udelukkende brug af "sustainable technologies" og for alt i verden undgå skelsættende teknologier. Når de så prøver så er hele forretningen geareet til det modsatte og så går det galt.

  • 1
  • 0
Ivo Santos

Jeg tør slet ikke at tænke på hvis alle de populær hjemmesider så som for eksempel Google, Youtube, eller Facebook havde samme performance som polsag. Så kunne jeg godt forestille mig et internet der konstant vil bryde sammen, og aldrig vil fungere ordentligt, altså!. Det lyder da næsten som om at en nybenynder burde kunne gøre et bedre arbejde.

  • 1
  • 0
Claus Jacobsen

En "havarikommision" ville være rar - men tænk lidt over det først - fly og tog gennemgår nogle sindsygt restriktive kvalitetskontroller før de kan blive godkendt til transport INDEN de bliver sendt ud i verden. Et sådant apparat findes vist ikke i sofwareverdenen, og SLET ikke i DK. Så jeg så måske i virkeligheden hellere at man havde en kvalifikations instans/kvalitetskontrol der gik et system igennem INDEN det blev leveret eller kom i test. og ALLE udviklingsomkostninger indtil da ville stå for leverandørs regning indtil godkendelsen er i hus. Og ligesom fødevarekontrollen - så ville de kunne komme på uanmeldt besøg :D Præcis ligesom MS kan sende KPMG ud for lige at tjekke om man nu også har betalt for de rigtige licenser.

Men det er jo det generelle problem med ting der ryger i udbud - hvis ikke det står i kravspec - så er det ligegyldigt, og man får ikke bonus for at levere en elegant løsning, kun den der er som absolut minimum påkrævet.

  • 0
  • 0
Kristian Sørensen

Det lyder meget besnærende med en it havari kommision.

Men hvordan vil du sikre at rekrutteringen til en sådan havari kommision ikke kommer til at foregå på samme måde som rekrutteringen til de kuldsejlede projekter?

Nogen har jo gjort deres bedste for at hyre de rigtige folk til alle disse offentlige (og private) it katastrofer.

Hvis der virkeligt er nogle andre der er så meget bedre til at rekruttere at de kan sammensætte en havarikommision med langt bedre folk, hvorfor så ikke bare lade dem vælge folk til kommende it projekter i stedet?

  • 2
  • 0
Poul-Henning Kamp Blogger

fly og tog gennemgår nogle sindsygt restriktive kvalitetskontroller før de kan blive godkendt til transport INDEN de bliver sendt ud i verden. Et sådant apparat findes vist ikke i sofwareverdenen, og SLET ikke i DK.

Det er ikke havarikommisionens opgave at finde ud af om papirarbejdet er korrekt udfyldt, det er deres opgave at finde ud af hvad der gik galt.

(Ikke sjældent har havarikommisioner peget på papirarbejdet som en stor del af årsagen til ulykker, se f.eks Challenger rapporten.)

Spørgsmålet om papirarbejdet, skyld og erstatning hører til foran domstolene.

  • 3
  • 0
Claus Jacobsen

vi er som sådan enige PHK - men i stedet for at rende rundt og pege fingre gik jeg så skridtet videre og kiggede på hvad der skulle til for at undgå det i fremtiden. og en kvalitetskontrol kunne være en af dem, men helt sikkert langt fra nok. Det er hele mentalitetn om cheap-first, working-later der skal vendes, og ikke mindst mindset omkring professionalisme er. Det er nemlig ikke pengerelateret men derimod indstilling. og det har man ikke haft i det offentlige heller.

  • 2
  • 0
Poul-Henning Kamp Blogger

en kvalitetskontrol kunne være en af dem

Kun hvis du har et kvalitetsmål at styre efter.

Det forudsætter en forståelse af hvad kvalitet er og hvordan man kan styre processen imod et givent defineret mål.

Den slags viden får vi kun adgang til, hvis vi begynder at lære af vores fejltagelser, frem for bare at grave dem ned og glemme dem hurtigst muligt.

Derfor, IT-Havarikommission, NU!

  • 4
  • 0
Henrik Eiriksson

Problemet er nok at ingen ægte mennesker bliver slået ihjel når sådanne systemer går i smadder. Det gør bare ikke ondt nok for it-branchen at fejle miserabelt.
Måske hvis prisen for at fejle var at 200 tilfældige mennesker blev samlet op fra gaden og dræbt, hvilket svarer til max. prisen for at et fly falder ned pga. teknisk fejl, ville kvaliteten blive taget alvorligt (?!).

Jeg fik måske en heldig start på min it-karriere. Fik lov at implementere styresystemer til en medicinalfabrik. Vi fik at vide at fejl kunne slå mennesker ihjel da slutproduktet skulle sprøjtes direkte ind i blodbanen. Vi testede indtil vi havde samme farve som smølfer og vi skulle derefter forbi de ledeste QA teams og trusler om fuld FDA inspektion. Opstod der fejl under test, skulle årsagen først redegøres til QA teamets (sjældne) tilfredsstillelse og derefter rettes og testes helt forfra. Det var sindsygt hårdt, men jeg kunne sove om natten.

Apropos fly, så kom jeg lidt senere, på en flyvetur, til at sidde ved siden af en test-ansvarlig for Rolls Royce Jet Engine Division (ja, det laver de også). Han gav mig et foredrag om test og kvalitetscheck jeg aldrig glemmer. De prøvede alt på de flymotorer. Bl.a. brugte de en kanon til at skyde frosne kyllinger gennem turbinen på fuld blast, bare for at være sikker på at flyet kunne tage et Albatros hit - mindst.

Det var en lang måde at sige at PHK har ret.

Vi mangler en mekanisme - en it-havarikommission - der skal afdække årsagen til disse it-katastrofer så erfaringerne kan gavne it-branchen. Ellers gentages katastroferne ad infinitum. Hvis vi virkelig ønsker at "digitalisere" samfundet så skal systemerne være i orden.

  • 7
  • 0
Finn Christensen

Det er ikke havarikommisionens opgave at finde ud af om papirarbejdet er korrekt udfyldt, det er deres opgave at finde ud af hvad der gik galt.

Hvad vil du opnå PHK - udover at smide flere penge lige ud af vinduet ?

@Jesper Kildebogaard
Polsag-systemet var nemlig tænkt som en mere teknologisk moderne videreførelse af det nuværende Polsas (fra 1997), så kravet var faktisk, at det lignede det gamle.....

Og det Jesper nævner er jo ikke helt usædvanligt for mange af de offentlige systemer - tværtimod. Alt for meget nyt kræver en massiv træning og undervisning i en driftsorganisation (sic! Politi er en sådan), som der hverken er ressourcer til, eller ønske om hos de ansatte. Offentlige systemerne er skabt over love, og opbygger via en praktisk organisation og dens regelsæt gennem utallige år. I dette tilfælde har politi + jura mange hundrede af år på bagen...

Tussegammel organisering + ny teknologi = kostbar tussegammel organisering(KTO).

Da KTO er en velkendt problematik, så laver man lige før eller undervejs også en omorganisering, og ja vi havde da sør'm lige en politireform, der trådte i kraft i 2007, og så får vi:

Tussegammel organisering + ny teknologi + omorganisering = særdeles kostbar tussegammel organisering.

Polsag havnede forventelig i en kendt grøft, og da konsekvenserne blev synlige så var der endelig en fornuftig sjæl, der trak stikket.

  • 2
  • 1
Lars F. Jensen

Hvis din applikation ikke ville skalere på i386, vil den heller ikke gøre det på nogen anden CPU.

Enig, nen det omvendte, at det skalerer på 1990 generation i386 systemer, betyder ikke nødvendigvis, at det denne skalering kan gå 10^n gange højere, blot ved at flytte til nyeste hardware.

Jeg har set adskillige systemer, hvor det gik OK med 2, 5, 10 endda 100 gange skalering, men som derefter gik helt og aldeles galt - uanset mængden af ny hardware.

Lars :)

  • 0
  • 0
Ivan Skytte Jørgensen

Jeg tror ikke at der kun er een kilde til alle dårligdommene. Men jeg kan forestille mig følgende:
1. De personer som kan stille krav er ikke de samme som er ansvarlige for budgettet.
2. Brug af firmaer som ikke får incitament til at eliminere sig selv.
3. Manglende brug af allerede eksisterende løsninger eller delløsninger

Delvist relateret ællebælle:
Jeg undrede mig lidt over da rejsekortprojektets besværligheder blev bla.a begrundet med at det var svært at lave alle de transactioner i realtid. Lidt udregning på bagsiden af en serviet (ok, i unix "bc"): 200 stationer (mit bud) med hver 6 rejsekortstandere og 10 sekunder mellem hver checkin/checkout på hver i peak = 120 transaktioner pr. sekund. Hmmm. hvis man betrager påstigningsstation og afstigningsstation som telefonnumre, så kunne mit firma annoncere 3000 transaktioner/sek tilbage i 2001. Svært? Nej. (og ja, jeg har læst hele takst-dokumentet fra resekort.dk)
POLSAG specifikt, så kan jeg forstille mig at der er ret meget integration med andre systemer. Men hvorfor har man dog valgt at implementere en gigantisk afløser for X antal eksisteremnde systemer i eet hug? De5t fornuftige vill have været at opsamle krav og ønsker fra de eksisterende sytemer, lave et ordentlig fleksiblet design og så erstatte systemer et efter et.

  • 0
  • 0
Benjamin Balder

Man skal gå på kompromis mellem smuk arkitektur og performance

Dette er ikke modsætninger. Og jeg genter: DETTE ER IKKE MODSÆTNINGER!! Komprimiset findes ikke, og hvis det gør, har man nogle andre fundamentale modsætninger.

  • 2
  • 0
Søren Jespersen

Ja, den må man så rette op på, når man har læst IT-havarikommisionens rapport og lade være med at gøre samme fejl næste gang.

Præcis som Tog og Fly.

Men PHK, det passer jo ikke..
Hvad har havarikommisionen for tog udtalt sig om udbuddet og indkøbbet af IC4? Det er trods alt en af de største skandaler vi længe har haft.

Indkøb og udbud ligger ikke hos havarikommisionen. De kigger i stedet på hvad der går galt når det indkøbte holder op med at virke.

  • 2
  • 1
Poul-Henning Kamp Blogger

Hvad har havarikommisionen for tog udtalt sig om udbuddet og indkøbbet af IC4?

Du overser at tog har en tilsynsmyndighed der skal godkende dem før de kommer på skinnerne. Derfor starter Havarikommisionens arbejde i det tilfælde først efter godkendelsen.

Jeg tror ikke vi er klar til at kræve godkendelse af IT systemer inden de må bruges, derfor må IT-havarikommisionen også dække den del af forløbet.

Den vigtige pointe er at vi skal lære af vores fejl.

Hvis du har nogen bedre forslag til hvordan det kan gøres, forslag som ikke tillader "kreative" politikere og IT-folk at smyge sig udenom eller under et stadigt højere placeret kvalitetskrav, må du meget gerne komme med dem.

Har du ingen bedre forslag, har jeg lidt svært ved at forstå hvad du har imod mit forslag ?

  • 5
  • 0
Carsten Larsen

For at bruge en velkendt frase: ORM er ikke en magisk sovs man hælder ud over ting og så bliver de på magisk vis billigere, bedre og hurtigere. Hver eneste gang en abstraktion inføres, herunderi form af ORM, koster det ekstra kode, der igen koster ekstra processorkraft at afvikle.

At abstrahere allokering af hukommelse og evt. processor arkitektur væk er en ting. Noget andet er når den fyske placering af data bortabstraheres. Det er altså ikke ligegyldt om data befinder sig i på en disk eller i RAM, eller på en helt anden maskine.

Performance og arkitektur er i høj grad modsætninger. Som oftest viser modsætningen sig bare ikke før hardware ikke længere kan kompensere. Målet med en arkitektur er da også sjældent performance.

  • 0
  • 0
Flemming Riis

Hvis du har nogen bedre forslag til hvordan det kan gøres, forslag som ikke tillader "kreative" politikere og IT-folk at smyge sig udenom eller under et stadigt højere placeret kvalitetskrav, må du meget gerne komme med dem.

Man burde udvide det til at alle større projekter satte 1% af til løbende review , og så bare bruge SME på området forskellige stedet i verden fra så det ingen interesser er.

Men at man bare fejer 500+ millioner i skraldespanden uden at lære af det er sindsygt.

  • 1
  • 0
Martin Kirk

Det lykkedes for mig at lægge CSC's mainframe ned da jeg spurgte efter data på sølle 65.000 nummerplader..

en operation som deres mainframe skulle bruge ikke mindre end 3 timer på !!!

såe ... der er intet der kan komme bag på mig med hensyn til CSC.

stort set alt hvad de røre ved bliver til lort.

  • 3
  • 0
Poul-Henning Kamp Blogger

Burde det ikke være et stående udvalg hos statsrevisionen?

Jeg så egentlig gerne at den havde et lige så bredt mandat som vores andre havarikommisioner: Selv hvis det er dit eget lille et-motorsfly du flyver ind i en bardunmast bliver det udredt af havarikommisionen.

På samme måde bør også banker og e-shops "tab" af personoplysninger kulegraves og det ligger temmelig langt fra statsrevisionens resort.

  • 1
  • 0
Mikkel Lauritsen

For at bruge en velkendt frase: ORM er ikke en magisk sovs man hælder ud over ting og så bliver de på magisk vis billigere, bedre og hurtigere. Hver eneste gang en abstraktion inføres, herunderi form af ORM, koster det ekstra kode, der igen koster ekstra processorkraft at afvikle.

Der er ikke noget galt med ORM, så længe man sørger for at håndtere begrænsningerne. Det er en dejligt hurtig måde at "bygge bro" mellem en (relationel) database og en objektorienteret model, og i mange tilfælde meget velfungerende, men som for alle andre abstraktioners vedkommende skal man gøre sig det klart, hvor der er mangler. Joel Spolsky havde i den grad fat i noget da han skrev om leaky abstractions.

At abstrahere allokering af hukommelse og evt. processor arkitektur væk er en ting. Noget andet er når den fyske placering af data bortabstraheres. Det er altså ikke ligegyldt om data befinder sig i på en disk eller i RAM, eller på en helt anden maskine.

Problemet gør sig også gældende på lavere niveau. Det er meget længe siden, at man kunne tillade sig at betragte maskinens hukommelse som et uniformt array af bytes - selv hvis man programmerer i ren assemblerkode bliver man nødt til at overveje, hvordan man tilgår data; det kan hurtigt betyde forskelle på flere hundrede procent i performance om man gør det på en hensigtsmæssig måde.

Men ja, naiv brug af ORM har potentiale til virkelig at introducere nogen seriøse performanceproblemer :-)

  • 0
  • 0
Carsten Larsen

... det kan hurtigt betyde forskelle på flere hundrede procent i performance om man gør det på en hensigtsmæssig måde.

Ja, og det er så ikke tilfældet her (side 11 nederst):

Den "løse" alt andet lige beregning af antallet af requests i uddannelsesmiljøet på 7.872.000 request pr. time (12 kredse) vil betyde at Oracle skal eksekverer 212,5 millioner SQL-sætninger pr. time eller 59.040 SQL sætninger pr. sekund, såfremt hvert http request i gennemsnit kræver 27 SQL-sætninger.

Data ændre sige næppe så meget, at det burde være nødvendigt. Ej heller burde der være en så stærk kobing til såkaldte "rendsystemer".

  • 0
  • 0
Morten Andersen

Det kritisable synes jeg ikke så meget er at systemet initielt performede dårligt. Det mest kritisable er at man ikke særdeles hurtigt har profilet den dårligt performende applikation, og gjort noget ved problemerne. Nu vil nogen måske indvende at det kan være meget svært når applikationen først er skrevet, men det er faktisk ikke min erfaring. Ofte kan man slippe afsted med selv enorme ændringer/udskiftninger af "motoren" under denne type systemer, og dermed opnå gigantiske forbedringer på kort tid... for meget af det der tager tid og koster penge i denne type systemer er det mere 'bløde' som UI, konfiguration, test cases m.m. som jo kan leve videre ovenpå en ny motor. Så man er slet ikke i nærheden af omkostningerne til et nyt system. Det eneste der kræves er et par skarpe IT-folk der går i krig.

Desuden, når man læser om det "overforbrug" af SQL der er tale om, som er et par størrelsesordener ved siden af, så MÅ der være massevis af lavthængende frugter der kunne give nogle seriøse forbedringer, uden de store sværslag.

Jeg tror den egentlige årsag har været en misforstået uvillighed til at ændre i hovedmotoren. Når problemerne er så massive som her, og kontrakten i alvorlig fare, burde man have forket al koden til ScanJour systemet og så ellers bare gjort det der skulle til - og jeg nægter at tro at dette ikke skulle kunne lade sig gøre (eller at det ville kræve noget nær en total nyudvikling af systemet).

  • 2
  • 1
Martin Berg

Kunne du ikke lige forklare, hvorledes manglende indexering har indflydelse på antallet af SQL-kald?
Derefter må du godt forklare lidt mere om, hvoraf i introduktionen til Oracle's struktur (dit link), du udleder at "data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"

  • 2
  • 0
Morten Andersen

Yep enig - i denne sag kender vi kun problemet overfladisk, og således ikke baggrunden for det store antal SQL-forespørgsler og hvad der evt. er gjort for at imødegå det. Problemerne er formentlig mindst ligeså meget "politiske" som tekniske. Uanset hvad, så er den slags detaljer typisk noget der holdes tæt til kroppen (det gælder såvel offentlige som private projekter) så de involverede personer kan formentlig ikke udtale sig, og krummer sikkert tæer hvis de læser historier/indlæg som her!

I det hele taget er der meget dansk IT-historie der går tabt pga. hemmelighedskræmmeriet. Man kan jo godt forstå at en privat virksomhed ikke vil udstille sine fejl, og dermed mindske muligheden for at vinde opgaver i fremtiden (ligesom man typisk ikke vil dele sine dyrkøbte erfaringer med konkurrenterne). Og i de offentlige projekter der også ofte private virksomheder der har en finger med i spillet. Men måske man kunne indføre en regel for offentlige IT-projekter om at der altid skulle udarbejdes en uafhængig rapport om forløbet, og at denne blev offentliggjort X år efter projektets afslutning (og selvfølgeligt anonymiseret i den grad det nu er muligt - navnene på involverede firmaer kan jo nok ofte hentes fra andre kilder, men man kan naturligvis beskytte de enkelte medarbejdere). Rapporten kunne dog være tilgængelig internt i det offentlige fra day 1, til brug for fremtidige udbud. X sættes ud fra hensyn til at rapporten ikke må skade de involverede firmaer for meget, og også ud fra offentlighedens interesse i at få informationer om projektet, mens de stadigvæk er interessante (og ikke overhalet af den teknologiske udvikling). F.eks. 5 år.

  • 0
  • 0
Finn Christensen

Hvad vil du opnå PHK - udover at smide flere penge lige ud af vinduet ?

Jeg vil opnå at vi får dokumenteret, offentliggjort, hvad der blev gjort galt så vi kan undgå at lave samme fejl næste gang.


Jeg vil til enhver tid støtte dig i et berettiget krav - men - rigsrevisionen og andre før dem har dokumenteret og offentliggjort - og det er dette systems form for havarikommission.

De ved godt hvad der gik galt og hvorfor.

Din form, det du ønsker og de metoder der bruges ifm. fly etc. vil aldrig finde anvendelse indenfor staten/kommuner o.lign., da den indeholder noget man ikke 'har brug for' i deres verden...

  • 0
  • 1
Michael Zedeler

Gad vide om applikationen overhovedet kan overleve at en betjent optager rapport på Bobby Tables?

Det er rystende at de har formået at udvikle så ringe et produkt. PHK skriver om en IT-havarikommission, men jeg tvivler på at udviklere som skriver den slags kode (og de ledere som har ansvaret for dem) er i stand til at lære noget af de rapporter, der kommer ud af det.

  • 2
  • 0
Mikkel Lauritsen

Kunne du ikke lige forklare, hvorledes manglende indexering har indflydelse på antallet af SQL-kald?


Det har det ikke. Manglende indeksering har betydning for, hvor lang tid det enkelte kald tager at eksekvere (og hvor hårdt det belaster databaseserveren), men med mindre man har lavet noget ualmindeligt skummel applikationskode betyder det intet for hvor mange databasekald der laves for at udføre et givent stykke funktionalitet.

Derefter må du godt forklare lidt mere om, hvoraf i introduktionen til Oracle's struktur (dit link), du udleder at "data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"


Den undrede også mig. SVJV er der ikke flere fundamentale forskelle på Oracle og relationel database X, end der er på database X og Y, Y != Oracle. Regler som at man skal minimere antallet af roundtrips, kun hente de data man skal bruge osv. er nærmest universelt gyldige.

  • 2
  • 0
Kai Birger Nielsen

Noget af den dårlige performance må også skyldes at specifikationen af systemet har været overladt til folk, der ikke viste hvad deres ønsker kostede.
Jeg har da mange gange siddet med brugere, når vi har udviklet et eller andet og oplavet dialoger som: "Bruger: vi vil gerne kunne bladre i poster og fx springe ind et bestemt sted i alfabetet. Udvikler: fint, men det er umådeligt tungt i det her framework, så svartiderne bliver ulidelige. Hvad med at kunne bladre 100 poster ad gangen? Det er ganske hurtigt. Bruger: Ok, det er næsten lige så godt at bladre, bare det er hurtigt."

Hvis man aldrig tager den slags dialoger, så ender man med noget smukt abstrakt kode, der bare aldrig når at rendere velkomstskærmen, før brugeren er gået på pension.

  • 2
  • 0
Janus Knudsen

Det værste i denne sag er at næste gang CSC byder på en offentligt udbudt aftale at der på ingen måde medtages POLSAG's fadæse, men at de offentlige licitationer beklageligvis styres af nogle helt andre interesser end succesrater og omkostninger.

Istedet for at nedsætte en havarikommision, burde man istedet kulegrave de ansvarshavende indenfor det offentlige der har godkendt denne opgave.

  • 8
  • 0
Claus Jacobsen

Jeg har været involveret i offentlige udbud hvor der under de juridiske krav stod, at der ikke må have været graverende fejl i tidligere vundne offentlige sager. - Det var da en let måde at fjerne CSC på fra den offentlige sektor fremadrettet! :D OG det ville i høj grad tvinge udbudstagere til at se længere frem end lige den nærmeste mio ordre - da det jo så i høj grad ville kunne give et alvorligt bagslag aåfremt der ville opstå tvister senere hen. OG man kunne forestille sig at firmaerne måske var lidt mere opmærksomme på hvad det er for noget de afleverer.

  • 3
  • 0
Janus Knudsen

Men så kan du måske fortælle hvorfor man laver vanvittige krav som SKI og ikke i langt højere grad benytter sig af lokale leverandører.

De fleste opgaver indenfor det offentlige vil kunne løses langt bedre af mindre firmaer hvor filosofien om at levere kvalitet stadig er intakt.

Det er jo ærgeligt at det offentlige benytter store udenlandske virksomheder til at løse opgaver som eks.vis Polsag, Elektronisk Patient Journal mv.

  • 1
  • 0
Jens Minnet

En interessant diskussion med mange gode argumenter - og med et teknisk niveau, jeg ikke kan følge med I.

Stort set al debatten går dog på, hvor store fjolser arkitekter og programmører hos CSC har været. Men hvad med Scanjour Captia, der anvendes som standardplatform?

Hvor meget af det "dårlige" design (mængden og strukturen af forespørgselsmængderne, som hele diskussionen tager udgangspunkt i) og den heraf følgende dårlige performance skyldes Scanjour systemet, og hvor meget skyldes CSC's implementering med tilhørende klisterkode m.v.?

Jeg har svært ved at tro, at CSC star for den overvejende mængde http forespørgsler og den heraf afledte mængde databasekald uden om Captia.

Er der nogen, der har konkret viden/erfaringer med det?

Det er såmænd ikke for at grise Scanjour til eller at frikende CSC - de har hovedansvaret for valg og/eller accept af platform, uanset hvordan kravspecifikationen har set ud. Alle ting har sin berettigelse i den rigtige sammenhæng. Men var Polsag den rigtige sammenhæng for Captia, hvis det var gjort rigtigt?

Det kunne være godt med et kvalificeret bud på dette.

  • 0
  • 0
Nikolaj Brinch Jørgensen
  • 1
  • 0
Nikolaj Brinch Jørgensen

Det er såmænd ikke for at grise Scanjour til eller at frikende CSC - de har hovedansvaret for valg og/eller accept af platform, uanset hvordan kravspecifikationen har set ud. Alle ting har sin berettigelse i den rigtige sammenhæng. Men var Polsag den rigtige sammenhæng for Captia, hvis det var gjort rigtigt?

Det kunne være godt med et kvalificeret bud på dette.


Jeg har også en fæl mistanke til ScanJour og Captia, for de er ofte involveret som ESDH system underleverandør i projekter der går i hegnet.

IT Havarikommision ville være kærkommen, når nu så mange skatteyderkroner ødsles bort på det rene ingenting. I hvert fald bør der laves karantæneperioder for virksomheder der i den grad er inkompente til at løse opgaver.

  • 2
  • 0
Christian Nobel

Men så kan du måske fortælle hvorfor man laver vanvittige krav som SKI og ikke i langt højere grad benytter sig af lokale leverandører.

De fleste opgaver indenfor det offentlige vil kunne løses langt bedre af mindre firmaer hvor filosofien om at levere kvalitet stadig er intakt.

Det er jo ærgeligt at det offentlige benytter store udenlandske virksomheder til at løse opgaver som eks.vis Polsag, Elektronisk Patient Journal mv.

Du har fat i noget helt centralt, nemlig det altødelæggende SKI monster.

Jeg plejer at bruge dette karikerede eksempel:

http://www.version2.dk/artikel/naesten-hver-fjerde-kunde-har-mistillid-t...

Det er helt klart, at sålænge at man inden for det offentlige kun lader ordrerne gå til the usual suspects, ud fra en djØF beskrivelse af hvad der er billigst, i stedet for at have pålidelige og troværdige samarbejdspartnere, så skal det gå galt.

Så hvis vi skal spare her i landet, så vil det være en rigtig god ide at luge ud i underlige regler og forordninger, og på samme tid tynde ud i djØFFERne i centralmagten - for min sags skyld vil det være en samfundsgevinst at lade dem komme på dagpenge, da det dels er en billigere form for offentlig forsørgelse end ansættelse i centalmagten, dels vil forhindre dem i at lave flere ulykker.
(Og der burde være nok at tage af, eksempelvis er antallet af akademikere i kommunerne steget voldsomt efter kommunalreformen, mens antallet af varme hænder er faldet drastisk - stik mod hele intentionen med sammenlægningerne!)

  • 2
  • 1
Christian Nobel

På nuværende tidspunkt, så fylder denne side, inklusive alle kommentarerne, billeder, CSS, overhead og hvad ved jeg, ca. 4,8 MB uncompressed.

Men nu er der jo væsentlig forskel på et nyhedssite med tilhørende debatforum, end et sagsbehandlingssystem - så der er noget helt, helt galt i opfattelsen af hvordan man skruer sådan noget sammen.

  • 0
  • 0
Rasmus Iversen

@Christian Nobel:

Du fredsens - den slags "namecalling" plejer at være noget man finder på eb.dk's "Nationen!", ikke på V2. Men det er vel nemmere at lange ud efter bureaukraterne end at forholde sig til mængden af SQL-kald? Jeg tvivler på at en DJØF'er kan tage ansvaret for, at det tal er kommet så højt op - så har vedkommende i hvert fald været ansat forkert. Det er vel sådan noget, det netop er de it-kyndige, der skal holde øje med :)

  • 0
  • 2
Christian Nobel

Muligvis er det mig er der en Klovn, men kigger jeg på network usage i Chrome for denne side er der overført 637kb, hvilket er langt fra dine 5.5mb.

Men jeg kan tage fejl.

Jeg har brugt Web Developers document size til at vise alt hvad der er relateret til siden, hvilket burde være alt der hives over, i hvert fald første gang, indtil der er cached noget.

Til sammenligning, så er document size kun 922 KB for V2's forside, og selv her må der jo vitterlig siges at være meget mere information end i et sagsstyringssystem.

  • 0
  • 0
Jens Minnet

Scanjour blev op til 2007 brugt hos Fyns Amt. Da jeg dengang lavede konsulentarbejde for amtet fik jeg det indtryk, at det fungerede rigtig godt hos dem.


Ja, Captia bliver brugt med success rigtigt mange steder. Derfor vil jeg heller ikke stille spørgsmålstegn ved kvaliteten af Captia i sig selv.

Captia er dog ikke lavet specifikt til Politiet, men til at lave ESDH i bred forstand - oprindeligt med udgangspunkt i journalisering med ganske kompleks regelhåndtering. Med tiden er det videreudviklet til at være mere vidensdelingsorienteret og procesunderstøttende.

Mig bekendt er systemet baseret på, at der konstant foretages databasekald, hver gang man bevæger sig rundt i sagsdata, som sagt underlagt en kompleks regelhåndtering.

Jeg skal ikke gøre mig klog på hvor mange af databasekaldene, der er relevante for Politiet, eller hvor mange der mere er til for den brede vifte af andre anvendelsesområder, som Captia adresserer, men som er overflødige for Politiets anvendelse.

Rapporten adresserer udelukkende antallet af http forespørgsler og de databaseopkald, som de medfører, set i forhold til den serverkapacitet, der er stillet til rådighed og dermed den oplevede performance. Den forholder sig ikke til, om disse mængder er voldsomme i forhold til anvendelsen eller ej, herunder om en eventuelt akademisk overdrevet kravspecifikation kunne være årsagen.

Jeg antager, at antallet af http forespørgsler er direkte betinget af Politiets anvendelsesmønster. Med 27 opslag pr. forespørgsel sker der godt nok noget i baggrunden. Det lyder i sig selv ret vildt. Og spørgsmålet er dernæst, hvor meget hvert opslag er optimeret performancemæssigt (som det meste af ovenstående discussion går på).

Og så er vi tilbage til, om Captia monstro var det rigtige valg af standardsystem eller ej, som Claus Jepsen også antyder tidligere i diskussionen.

  • 0
  • 0
Martin Berg

Tak Mikkel - det var nu egentlig også mit billede af (database)verdenen, men jeg er da indstillet på at blive klogere ;-)

Faktisk ville jeg med en tilstrækkeligt vanartet applikation ikke blive overrasket over at manglende index gav FÆRRE SQL i den situation, hvor brugerne venter i kø på at blive serviceret af databasen.

  • 0
  • 0
Janus Knudsen

Tak Mikkel - det var nu egentlig også mit billede af (database)verdenen, men jeg er da indstillet på at blive klogere ;-)

Faktisk ville jeg med en tilstrækkeligt vanartet applikation ikke blive overrasket over at manglende index gav FÆRRE SQL i den situation, hvor brugerne venter i kø på at blive serviceret af databasen.

Så du mener at fordi eksekveringen af SQL'en tager længere tid vil der blive udført færre SQL-kald?

Ja, enig... men hvorfor skulle det være fordelagtigt?
- Hvori skulle forskellen ligge om man udfører 100 eller 1? 100 vil da altid være at foretrække på det samme antal IO's.

  • 0
  • 0
Janus Knudsen

Martin Berg og Mikkel, I må da lige forklare hvad bevæggrunden for jeres indlæg er?

Kunne du ikke lige forklare, hvorledes manglende indexering har indflydelse på antallet af SQL-kald?

Det har det ikke. Manglende indeksering har betydning for, hvor lang tid det enkelte kald tager at eksekvere (og hvor hårdt det belaster databaseserveren), men med mindre man har lavet noget ualmindeligt skummel applikationskode betyder det intet for hvor mange databasekald der laves for at udføre et givent stykke funktionalitet.

Derefter må du godt forklare lidt mere om, hvoraf i introduktionen til Oracle's struktur (dit link), du udleder at "data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"

Den undrede også mig. SVJV er der ikke flere fundamentale forskelle på Oracle og relationel database X, end der er på database X og Y, Y != Oracle. Regler som at man skal minimere antallet af roundtrips, kun hente de data man skal bruge osv. er nærmest universelt gyldige.

Hvad betyder "men med mindre man har lavet noget ualmindeligt skummel applikationskode betyder det intet for hvor mange databasekald der laves for at udføre et givent stykke funktionalitet."
- Applikationskode vil altid belaste SQL-serveren når det ikke hentes fra cachen.
- Mener du hermed at antallet af databasekald er ligegyldigt for performance?

"data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"
- Oracle er vidst blot en relationel database, hvad mener du med rigtige?

"Regler som at man skal minimere antallet af roundtrips, kun hente de data man skal bruge osv. er nærmest universelt gyldige."
- Det er vidst lige omvendt (mere eller mindre) ;-), hurtig ind hurtig ud er reglen, små transaktioner istedet for store.

  • 0
  • 0
Martin Berg

Du skal læse det oprindelige indlæg, som jeg svarer på.
Her fremføres manglende indexering som en mulig forklaring på Polsags 100.000 SQL i sekundet.
Det er noget vrøvl - da manglende indexering ganske som Mikkel skriver kun vil have betydning for svartiden af en SQL, og ved en given funktionalitet ikke have betydning for antallet af SQL (med mindre da man har skrevet noget uhyre skummel = destruktiv kode)

Mit opfølgende svar siger intet om at det er fordelagtigt - det var en kommentar til at manglende indexering om noget vil kunne give færre SQL per sekund, hvis database serveren har travlt - i modsætnings til det oprindelige indlægs påstand om at manglende indexering kunne være årsag til 100.000 SQL/sek (som normalt vil betragtes som et MEGET højt tal)

  • 0
  • 0
Martin Berg

Hvad betyder "men med mindre man har lavet noget ualmindeligt skummel applikationskode betyder det intet for hvor mange databasekald der laves for at udføre et givent stykke funktionalitet."
- Applikationskode vil altid belaste SQL-serveren når det ikke hentes fra cachen.
- Mener du hermed at antallet af databasekald er ligegyldigt for performance?

"data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"
- Oracle er vidst blot en relationel database, hvad mener du med rigtige?

"Regler som at man skal minimere antallet af roundtrips, kun hente de data man skal bruge osv. er nærmest universelt gyldige."
- Det er vidst lige omvendt (mere eller mindre) ;-), hurtig ind hurtig ud er reglen, små transaktioner istedet for store.


Jeg går ud fra at du mener data og ikke applikationskode hentes fra cachen?

Når Mikkel omtaler "skummmel kode", så skal du forstå det som en tænkt konstruktion, som ingen håber/forventer at støde på i den virkelige verden.

Og det er faktisk muligt at forestille sig at en hjernedød programmør finder på at sende endnu flere SQL mod databasen jo langsommere den svarer.

I den normale rationelle verden for system udvikling vil derimod en given funktionalitet med en given datamængde og en given caching give det samme antal SQL uanset indexeringen.

Og "Nej" antallet af SQL er ikke ligegyldigt for performance - hvorfor tror du det?

Kommentaren om "rigtige relationelle" databaser kommer fra det oprindelige indlæg - prøv at spørge her hvad der menes.
Faktisk er både mit og Mikkels svar en kommentar til det oprindelige indlæg at det ikke giver mening at omtale Oracle som en "mindre rigtig" relationel database.

Og så må jeg sige at din ide om små databasekald styrer direkte mod en af de hovedårsager til manglende skalerbarhed, som som jeg (og andre performancetunere) har set en del gange.
I nogle udgaver kalder vi det "death by single row"

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det er vidst lige omvendt (mere eller mindre) ;-), hurtig ind hurtig ud er reglen, små transaktioner istedet for store

Og så må jeg sige at din ide om små databasekald styrer direkte mod en af de hovedårsager til manglende skalerbarhed, som som jeg (og andre performancetunere) har set en del gange.
I nogle udgaver kalder vi det "death by single row"

Der er ikke nogen regler her. At stille regler op for dette, giver lige nøjagtigt problemer. Transaktioner skal have lige præcis den størrelse de skal have. Men transaktioner og helt specifikt distribuerede transaktioner er non-scalable.

Oracle kan da sagtens håndtere 100K SQL forspørgsler/sek. Det er da bare at købe en Exadata dimmer. Men mon ikke Polsag som system, ikke lige brude have krav herom.

En af de kinesiske banker har 150 mio. privatkunder, mon ikke der medfører en hel del transaktioner. Men de benytter måske DB2 :-)

  • 0
  • 0
Mikkel Lauritsen

Hvad betyder "men med mindre man har lavet noget ualmindeligt skummel applikationskode betyder det intet for hvor mange databasekald der laves for at udføre et givent stykke funktionalitet."
- Applikationskode vil altid belaste SQL-serveren når det ikke hentes fra cachen.
- Mener du hermed at antallet af databasekald er ligegyldigt for performance?

Nej - tværtimod. "Det" henviser til indeksering, og min pointe var, at det oprindelige udsagn om at manglende indeksering skulle medføre flere roundtrips lød lidt mærkeligt. Det skulle ikke undre mig, om nogen har fundet på at lave noget PGO-agtigt, så et manglende indeks giver anledning til ændrede queries, men det har jeg endnu ikke set i et ORM-lag.

"data i Oracle ikke helt opfører sig som data i andre, rigtige relationsdatabaser"
- Oracle er vidst blot en relationel database, hvad mener du med rigtige?

Nu er der vist opstået lidt citatforvirring. Det var ikke mig, som skrev, at Oracle ikke er en rigtig database. Au contraire, så mener jeg, at Oracle i det store hele opfører sig som de fleste andre relationelle databaser.

"Regler som at man skal minimere antallet af roundtrips, kun hente de data man skal bruge osv. er nærmest universelt gyldige."
- Det er vidst lige omvendt (mere eller mindre) ;-), hurtig ind hurtig ud er reglen, små transaktioner istedet for store.

Som jeg skrev, så skal man kun hente de data, som man skal bruge, men i øvrigt skal man sørge for at minimere antallet af roundtrips, fx jfr. mit eksempel fra før med at iterere gennem en collection. Selv med connection pooling, prepared statements og andre fiksfakserier er der et stort overhead forbundet med at foretage et roundtrip. Hvis nogen skulle være i tvivl om det, så lav en lille test, hvor man sammenligner den tid det tager at læse X records i et kald med den tid det tager at læse de samme X records med individuelle kald.

Der findes så scenarier, hvor man kan få samme funktionalitet ved fx enten at hente 100 records i et roundtrip eller 21 records i tre roundtrips, og hvor det ikke er oplagt, hvad der er den bedste løsning, fordi det afhænger af en lang række ting, og måske ændrer det sig endda over tid, efterhånden som databasens metrikker ændrer sig. Det vil nok føre for vidt at gøre denne kommentar i den tynde ende af en diskussionstråd til en større diskussion af emnet, men jeg uddyber gerne :-)

  • 0
  • 0
Janus Knudsen

Hej Martin

Og så må jeg sige at din ide om små databasekald styrer direkte mod en af de hovedårsager til manglende skalerbarhed, som som jeg (og andre performancetunere) har set en del gange.
I nogle udgaver kalder vi det "death by single row"

Vi er på samme side her :), jeg har brugt 10 år på db-tuning og kan læse ud af konteksten som du skriver at vi mener det samme.

Jeg er hverken tilhænger af store joins eller små transaktioner, men I at finde den bedste vej fra applikation til database. Det som jeg ofte ser er at udviklere totalt glemmer at der faktisk ligger en relationel db nedenuden og fuldstændig misbruger den pga. af en eller anden idé om ORM, dataload osv. skulle læse alle problemer for dem.

  • 0
  • 0
Janus Knudsen

Som jeg skrev, så skal man kun hente de data, som man skal bruge, men i øvrigt skal man sørge for at minimere antallet af roundtrips, fx jfr. mit eksempel fra før med at iterere gennem en collection. Selv med connection pooling, prepared statements og andre fiksfakserier er der et stort overhead forbundet med at foretage et roundtrip. Hvis nogen skulle være i tvivl om det, så lav en lille test, hvor man sammenligner den tid det tager at læse X records i et kald med den tid det tager at læse de samme X records med individuelle kald.

Må jeg undlade at åbne og lukke connectionen hver gang? ;-)

Tror nu nok også vi er på samme side her, du og Martin var bare knapt så detaljerede igår og det var derfor jeg lige ville høre hvad det var i snakkede om.

Jeg kan kun være 100% enig om at dataens metrikker kan/ vil ændre sig over tid, hvilket gør det vigtigt at have en god databasemand til både hw-forståelse, tsql og applikationsforståelse.

Ingen kan designe et system på papiret.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Jeg er hverken tilhænger af store joins eller små transaktioner, men I at finde den bedste vej fra applikation til database. Det som jeg ofte ser er at udviklere totalt glemmer at der faktisk ligger en relationel db nedenuden og fuldstændig misbruger den pga. af en eller anden idé om ORM, dataload osv. skulle læse alle problemer for dem.


Nu kan det jo også være at lige præcis RDBMS ikke var det rigtige værktøj i situationen. Alt for ofte går det galt når man presser en ikke-tabulær relationel model, ned i et RDBMS. Der er så mange data stores til de mange forskellige data strukturer der er, så lad os nu starte med ta vælge det rigtige, og ikke bare altid hælde penge efter Oracle, Microsoft & IBM, fordi det er det eneste DB-afdeligen kan finde ud af.

  • 0
  • 0
Mikkel Lauritsen

Må jeg undlade at åbne og lukke connectionen hver gang? ;-)

Ja. Som jeg skrev, så løser connection pooling ikke problemet; roundtrips er dyre uanset hvad. Jeg havde ikke stødt på Martins "death by single row" før; den er nu føjet til mit ordforråd.

Ingen kan designe et system på papiret.

Det er korrekt, at det i nogen situationer kan være svært at forudsige, hvilken runtimeperformance et kald af en relationel database kommer til give, bl.a. fordi det er grænsende til sort magi hvordan eksekveringen af en given query forløber. Det betyder dog heldigvis ikke, at der ikke findes nogen brugbare generelle retningslinjer for hvordan ens kode skal omgås databasen, og de 100.000 kald i sekundet som diskussionen startede med er med 100% sikkerhed helt ude i hampen.

  • 0
  • 0
Log ind eller Opret konto for at kommentere