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

23. august 2013 kl. 10:55106
Derfor kiksede Polsag: Krævede 100.000 SQL-kald i sekundet
Illustration: Das Büro.
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

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.

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.

Artiklen fortsætter efter annoncen

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.

Artiklen fortsætter efter annoncen

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.

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):

Remote video URL

106 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
95
26. august 2013 kl. 15:22

....kunne jo også skyldes amatørprogrammører fra verdens næstmest folkerige land....

90
26. august 2013 kl. 11:34

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.

92
26. august 2013 kl. 12:22

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.

93
26. august 2013 kl. 12:38

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.</p>
<p>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.

80
26. august 2013 kl. 09:41

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.

94
26. august 2013 kl. 13:06

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.

84
26. august 2013 kl. 10:21

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?</p>
<p>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.

86
26. august 2013 kl. 10:59

Her kan man se hvad der er fikset i en tilfaeldig version af Captia. [url]http://support.scanjour.dk/tekniskinformation/VersionsOversigt/Captia_4-5/..%5Crelease_notes%5C4.5.762.0%20SP1%5CReleaseNotes.pdf[/url] - soeg paa performance. Her er det et manglende index. Det tyder paa at der ikke er lavet meget profilering.

77
25. august 2013 kl. 15:41

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.

78
25. august 2013 kl. 21:03

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.

79
26. august 2013 kl. 09:39

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.

88
26. august 2013 kl. 11:04

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.</p>
<p>De fleste opgaver indenfor det offentlige vil kunne løses langt bedre af mindre firmaer hvor filosofien om at levere kvalitet stadig er intakt.</p>
<p>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-til-ski-50575#comment-230122

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!)

91
26. august 2013 kl. 11:35

@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 :)

76
25. august 2013 kl. 11:11

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.

73
25. august 2013 kl. 01:07

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.

66
24. august 2013 kl. 20:10

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).

68
24. august 2013 kl. 22:05

Det kritisable synes jeg [...]

Det mest kritisable er at vi ikke prøver at lære af vores fejltagelser på en struktureret måde, ved faktisk at klarlægge hvad der gik galt.

69
24. august 2013 kl. 23:25

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.

62
24. august 2013 kl. 14:07

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.

60
24. august 2013 kl. 12:01

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

63
24. august 2013 kl. 14:40

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.

55
24. august 2013 kl. 00:11

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.

49
23. august 2013 kl. 17:11

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.

43
23. august 2013 kl. 15:57

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?

41
23. august 2013 kl. 15:54

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.

35
23. august 2013 kl. 14:34

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.

30
23. august 2013 kl. 13:55

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

26
23. august 2013 kl. 13:22

@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.

11
23. august 2013 kl. 12:07

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.

36
23. august 2013 kl. 14:51

Never attribute to malice that which is adequately explained by stupidity.

7
23. august 2013 kl. 11:51

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)

9
23. august 2013 kl. 12:01

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.

17
23. august 2013 kl. 12:23

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

14
23. august 2013 kl. 12:13

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.

12
23. august 2013 kl. 12:10

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.

15
23. august 2013 kl. 12:14

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.

18
23. august 2013 kl. 12:23

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å....

20
23. august 2013 kl. 12:48

Ikke at forglemme, en komplet oversigt over hvem der skal citronmåne med de næste otte år ud i fremtiden...

21
23. august 2013 kl. 13:04

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

33
23. august 2013 kl. 14:28

Det har nok noget at gøre med, at de mobile terminaler dengang ikke havde et Microsoft logo et eller andet sted, og derfor er ude af synsvidde for dansk offentlig IT.

22
23. august 2013 kl. 13:08

[slettet dobbeltpost]

24
23. august 2013 kl. 13:14

Så det vi reelt kigger på er noget i stil med det screenshot der er på:</p>
<p><a href="http://www.scanjour.dk/en-GB/ECM-products/Products-for-the-public-secto…;.

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.

25
23. august 2013 kl. 13:20

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.

16
23. august 2013 kl. 12:17

Og bare lige for at skære det helt ud i pap:

En applikation som POLSAG må forventes at blive mobil indenfor få år og derfor SKAL man naturligvis tænke på hvor meget båndbredde der skal bruges og hvor lidt man kan klare sig med.

19
23. august 2013 kl. 12:43

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.

5
23. august 2013 kl. 11:37

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!

85
26. august 2013 kl. 10:46

Der er 10400 politifolk i Danmark.
.....

Jeg formoder det er i alt?

Og da politiet jo i det store hele er døgnåbent, og der er mange betjente der kører rundt i biler eller på motorcykler, hvor mange samtidige brugere taler vi så om?

Så jeg tror dit regnestykke skal "forværres" med mindst en faktor 3!

Hvilket gør det endnu mere utilgiveligt.

6
23. august 2013 kl. 11:50

var netop ved at lave samme udregning.

Det er jo helt vildt og jeg stolede ikke på mine egne udregninger og måtte regne det igennem 2 gange.