Kæmpebilleder i frimærkeformat lagde folketinget.dk ned - igen

Uskalerede JPEG-billeder på seks megabyte af alle folketingspolitikerne brugt som thumbnails fik torsdag det relancerede folketinget.dk til at bryde sammen igen, efter der også var problemer ved premieren tirsdag.
44

Alt for store billedfiler var én af årsagerne til, at Folketingets spritnye hjemmeside torsdag blev lagt ned i kølvandet på Folketingets åbningsdebat.

Serverne blev sidst på eftermiddagen genstartet for midlertidigt at lette trykket, mens Folketingets it-afdeling arbejdede på at løse problemerne.

»Vi har netop genstartet serveren, men det er nok et problem, som kommer igen,« siger it-udviklingschef i Folketinget Liselotte Astrup.

Indtil videre har it-afdelingen identificeret i hvert fald ét problem, som har været skyld i driftsproblemerne: Flere billeder på hjemmesiden blev distribueret i høj opløsning.

Det gjaldt blandt andet portrætterne af folketingspolitikerne, hvor den store version på typisk fem til seks megabyte blev brugt til at vise thumbnails på hjemmesiden og blot skaleret i brugerens browser.

På den måde blev der overført mange unødvendige megabytes for visningen af en politikers profilside på folketinget.dk, og det var med til at lægge pres på serverne.

Det problem er it-afdelingen nu ved at implementere en løsning på, så der i stedet bliver distribueret en lille version af billedet i en lavere opløsning og en mindre filstørrelse, hvilket skulle give mindre belastning af serveren.

Ifølge Liselotte Astrup er der nu også blevet nedsat en arbejdsgruppe, som skal se på hjemmesidens ydelse for at få løst de problemer, der opstår.

»Vi skal også kigge på caching. Vi bruger det allerede, men det er måske noget, man kan optimere mere,« siger Liselotte Astrup.

Folketingets nye hjemmeside, som kører på det danske CMS Sitecore, havde premiere tirsdag samtidig med Folketingets officielle åbning.

Tirsdag eftermiddag blev siden imidlertid overbelastet på grund af blandt andet trafik fra søgerobotter, som var i færd med dels at kontrollere gamle udløbne links og dels at indeksere den nye side.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (44)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Deleted User

Det må være et håbløst inkompetent IT-firma som har lavet det system.

Hvor mange af skatteydernes penge har vi nu spildt igen?

Det er utroligt at så dårlige udviklere rent faktisk har arbejde, endda under en finanskrise hvor der burde være mange om buddet.

  • 1
  • 0
#3 Anders Gregersen

Ingen løsninger er bedre end det svageste led. At en eller flere personer ligger hires billeder på et website uden at tænke over konsekvenserne er jo ikke systemet eller udviklernes skyld. Det svarer jo til at sige at det er DTP programmet eller offsets skyld at et lowres billed bliver trykt. Jo det ville da være rart at værktøjer beskyttede imod de væste dumheder, men det ved vi alle at vi ikke vil betale for.

  • 0
  • 1
#4 Allan Jacobsen

Til Anders, Nej det er ikke altid kompetente personer, der betjener systemerne, men et fornuftigt CMS havde selv skaleret billederne ned i en fornuftig størrelse, det har TYPO3, som jeg mest arbejder med, gjort i alle de 5+ år jeg har brugt det.

At det så også havde sparet skatteborgerne en hel del penge er en anden sag.

  • 2
  • 0
#5 Flemming Bach

Er ganske enig. Det undrer mig også, at de ikke har tænkt deres løsning igennem, inden at de startede udviklingen.

Det er jo ikke bare en lille webside, det er trods alt en side, som man (muligvis) kan forvente en stor del af Danmarks befolkning kigger forbi. At man ikke har optimeret og dimensioneret systemet fra starten af, er ganske simpelt for dårligt. Det er noget, som man lærer på næsten alle IT-uddannelser i dag som en af de første ting.

Det ligner lidt, at man har kastet en pose penge ud og håbet på, at der kan laves et system for beløbet. Hvilket har givet det resultat, som man kan følge med i her på Version2. ;)

  • 0
  • 0
#9 Claus Jacobsen

Men desværre voldsomt amatøragtigt at deres webredaktører ikke er i stand til at generere en thumbnail af et billede inden de uploader det til deres cms. Det har intet med udviklerne at gøre, men ene og alene at den person som har bygget siderne op, har glemt en helt basal ting. Det har hverken noget med webcaching eller automatisk skalering at gøre. Det er et spm om at redaktøren af siden rent faktisk har en forståelse for basal web-opbygning. I dette tilfælde har opbygningen af siden så været overdraget til en person som ikke har den fjerneste anelse om bearbejdning af grafik eller webopbygning. Det er jo desværre problemet (og fordelen!) ved CMS'er af denne størrelse. At det giver personer uden den store faglige viden mulighed for at kunne lave indhold til siderne på en måde så det er i tråd med de retningslinjer der er afstukket fra dem der ved noget om det. I dette tilfælde gik det så bare grueligt galt. og redaktøren har med sikkerhed lært noget! :-)

  • 0
  • 0
#13 Christian Nobel

Det er ligeså kløgtigt som retsinfo, hvor en af bekendtgørelserne består af en b[/b] side på over ½ GByte, udelukkende lutter indscannede sider, som billedfiler af tekst!

Og så (nogen må gerne forklare hvorfor) lykkes det åbenbart asp servere at overtage magten over browseren, så eneste udvej, mens ens internetforbindelse er ved at blive rødglødende er at slå browseren ihjel.

Hvis man henvender sig til retsinfo, så får man spitzenklasse svar:

Tak for din henvendelse af 6. juli 2009 vedrørende bekendtgørelse nr. 617 af 26. juni 2009. Vi er opmærksomme på, at det kræver mere kapacitet end sædvanligt at åbne siden.

Mere kapacitet end sædvanligt - suk.

/Christian

  • 0
  • 0
#14 Maciej Szeliga

Det er ligeså kløgtigt som retsinfo, hvor en af bekendtgørelserne består af en (en) side på over ½ GByte, udelukkende lutter indscannede sider, som billedfiler af tekst!

Det er jo bilaget fra EU som fylder... det meste i Retsinfo i ren tekst. Jeg vil tro at det er fordi de ikke ville ændre i bilaget.

Og så (nogen må gerne forklare hvorfor) lykkes det åbenbart asp servere at overtage magten over browseren, så eneste udvej, mens ens internetforbindelse er ved at blive rødglødende er at slå browseren ihjel.

Forkert browser måske ? ;-) I Firefox 3.0.x med NoScript på Linux kunne jeg godt lukke det låste faneblad.

Det er i øvrigt indholdsleverandørernes våde drøm at have en webserver som kontrollerer din browser, vidste du ikke det ?

  • 0
  • 0
#15 Nikolaj Brinch Jørgensen

Det vil det ikke er projektets udviklere (som sikkert har måttet leve med en fastpris kontrakt på 10 mio.), der har dummet sig, men igen en ledelse af et software indkøb, der har investeret i et inkompetent stykke CMS software? I det her tilfælde Sitecore.

  • 0
  • 0
#16 Anonym

Lad mig starte med min holdning gennem knap 30 år som udvikler: Der findes [b]ikke[/b] dumme brugere, kun [b]dumme systemer[/b]!

I den forbindelse synes jeg det er uhørt at brugeren (redaktøren?) skal tage stilling til, og bruge tid på at skalere billeder inden upload.

Normal praksis, som selv nybegyndere kan finde ud af, er, at lave en upload funktion.

Denne funktion skal kunne modtage en arbitrær størrelse af en given fil og [b]selv[/b] skalere til den ønskede størrelse.

Så forretningsgangen for en uploadfunktion er ca: 1) Modtag billedet (i systemet) 2) Hvis width > maxwidth eller height > maxheigt, så skaler ned til den ønskede størrelse, hvor man bevarer aspect ratio. [b]Samtidig[/b] dannes en thumbnail i den ønskede størrelse. 3) Disse 2 filer gemmes, og evt. en højopløselig (originalen), hvis man skal lave plakater.

Så er der nogle der mener (ud fra et brugersynspunkt), at man kan benytte billedet som thumbnail ved at skalere ned i browseren, da det store billede derved er tilgængeligt i browserens cache. Men det forudsættter, at man vil se 'det store billede', ellers er det total spild af båndbredde.

Ud fra artiklen, lyder det som om man har begået de mest fundamentale fejl, altså: - Undlade at skalere ned servereside. - Undlade at generere thumbnails.

Suk - disse ting har man kunnet finde på nettet gennem formentlig en halv snes år.

Vi skal også kigge på caching

Caching hjælper ikke på det faktum, at man bruger ~873 KB på en simpel forside. Det vil være bedre at muge ud i møget.

(Eller købe en 1Tbps linie)

  • 0
  • 0
#17 Christian Nobel

Det er jo bilaget fra EU som fylder... det meste i Retsinfo i ren tekst. Jeg vil tro at det er fordi de ikke ville ændre i bilaget.

Ja, men indholdet er ren tekst, så lur mig om ikke det eksisterer i elektronisk format - jeg tvivler det er lavet på en gammel IBM kuglehovedmaskine.

Og ellers så er der altså noget der hedder OCR.

Herudover, hvis de så endelig skulle lave noget så tåbeligt, så kunne de i det mindste dele bilaget op i bidder, som lå på egne sider, og så linke til dem - på den måde undgår man at loade ½G data for at læse selve bekendtgørelsen der fylder nogle få kb.

/Christian

  • 0
  • 0
#18 Jesper Utoft

Det burde næsten kræve at firmaet der har lavet siden får en bøde.

De må jo ikke have en skid forstand på hjemmesider. Selvom jeg kun laver hjemmesider til privat brug har jeg da aldrig gjort noget SÅ DUMT!

  • 0
  • 0
#19 Ole Juul

De siger at

Vi har netop genstartet serveren, men det er nok et problem, som kommer igen,

Så er det jo ikke store jpegs der er problemet for det kan man jo rette på kort tid. Skulle de så ikke have lidt mere bandwidth eller en ny server?

  • 0
  • 0
#20 Liv Madsen

Er der nogen af de folk, der kritiserer sitecore, som rent faktisk har arbejdet med systemet?

Jeg er helt enig i, at det ikke bør være webredaktørens ansvar manuelt at generere thumbnails af billeder til sitet, især ikke da man sagtens kan forestille sig, at det samme billede skal anvendes i mange forskellige dimensioner på et site. Men sitecore har faktisk en glimrende, indbygget funktion til dette. Det eneste, det kræver er, at udvikleren angiver den ønskede bredde, højde, maxbredde, maxhøjde etc. hvor billedet udskrives, så skaleres det serverside og gemmes i cachen. Simpelt og godt.

Ifølge min erfaring er sitecore et virkeligt fint CMS, med mange muligheder for effektiv performanceoptimering, men tankeløs brug af systemet kan selvfølgelig give nogle ret uheldige resultater. Uden at kende de nærmere omstændigheder, vil jeg antage, at skylden ligger hos udviklerne, ikke softwareindkøberne.

Jeg vil gerne tilslutte mig Stig Johansens holdning, dog med en lille tilføjelse: Der findes ikke dumme brugere, kun dumme systemer - og uvidende udviklere.

  • 0
  • 0
#21 Nikolaj Brinch Jørgensen

Jeg vil gerne tilslutte mig Stig Johansens holdning, dog med en lille tilføjelse: Der findes ikke dumme brugere, kun dumme systemer - og uvidende udviklere.

Hmmm. Hvordan hænger din holdning her sammen med at Sitecore fungere? Det er vel systemet der er dumt, fordi det har tilladt brugerne (udviklerne og/eller redaktøren) at lave noget som får systemet i knæ.

  • 0
  • 0
#22 Henrik Gedionsen

Det er vel systemet der er dumt, fordi det har tilladt brugerne (udviklerne og/eller redaktøren) at lave noget som får systemet i knæ

Jeg vil give dig fuldstændig ret. Det må helt klart være PC-systemet der er noget galt med. Hvis man havde brugt en Wii i stedet for, så kunne (udviklerne og/eller redaktøren) ikke lave noget galt. Hvis man ikke kan lave noget galt, så er der som regel ikke nogle muligheder.

Hvis pågældende udviklere havde lavet det i PHP eller et andet CMS, så havde de jo lavet samme fejl.

  • 0
  • 0
#23 Henrik Gedionsen

Hvis pågældende udviklere havde lavet det i PHP eller et andet CMS

Inden jeg bliver flamet om PHP ikke er et CMS, så lad mig omformulere: Hvis pågældende udviklere havde lavet det i from scratch i PHP eller et andet CMS end Sitecore

  • 0
  • 0
#26 Liv Madsen

Noget det ser ud til, deraf tilsyneladende.

Som tidligere skrevet, kender jeg jo ikke de nærmere omstændigheder omkring udviklingen og kan derfor på basis af de præsenterede informationer og mit sitecore-kendskab blot antage, at det omtalte issue skyldes et mindre glitch i udviklingen - eller en mangel i kravsspecifaktionen eller kvalitetskontrollen, om man vil :)

  • 0
  • 0
#29 Tom Paamand

Folketinget var ret tidligt ude med et flot og effektivt system, der hurtigt gjorde det muligt at følge med i deres arbejde. Senere har de så klistret en mere imødekommende (og rigeligt overlæsset) portal foran, men heldigvis var dokument-oversigten fortsat i et mere minimalt design.

Nu er dokument-oversigten så desværre blevet fuldt integreret i det stadigt tungere layout. En mere elegant løsning kunne være at udnytte CMSets fleksibilitet, og give brugerne mulighed for frit at vælge mellem lagkagepynt og et strammere design.

Samtidig er alt før 2004 efterladt i en skuffe for sig, med forkerte billedlinks. Det betyder, at almindelige søgninger behændigt glemmer fortiden, hvad de fleste politikere vel er godt tjent med...

Også alle vore gamle links ender nu i en ikke særligt imødekommende fejlside. Lidt simpel programmering kunne have genereret det korrekte link ud fra det gamle, men det er åbenbart for meget forlangt...

Endelig kræver links til mail-adresserne en lokal email-opsætning, hvilket udelukker kontakt via webmail etc, da systemet ikke på en nem måde fortæller adressen.

Det hele virker lidt forhastet og uigennemtænkt, men det kan vel nå at komme på plads. Ovenstående er også skrevet til webmasteren.

  • 0
  • 0
#32 Claus Waldersdorff Knudsen

Nej, nej, nej... De er, i skrivende stund, vist ikke helt færdige med overarbejdet derinde på borgen!

Checkede lige DF (!) og her er properties for Pia Adelsteens thumb nail billede: 3632px × 3632px (scaled to 84px × 84px) 5602.77 KB (5737239 bytes)

  • Og for Liselott Blixt: 84px × 84px 7.71 KB (7895 bytes)

Ku' ikk' li' la' være :-)

/Claus

  • 0
  • 0
#34 Niki Nicolas Grigoriou

Vi kan alle begå fejl. Og det er derfor vi tester.

Det virker ikke som om der udført tilstrækkelige performance-test af folketingets system i det her tilfælde. Når det samtidig går 'live' samme dag, som folketinget har åbningsdebat virker næsten overmodigt.

Jeg undres - hvad er der blevet udført af test forud for lanceringen, og hvordan har man vurderet risikoen ved at 'gå live' med et nyt system på en af de dage, hvor man på forhånd må kunne forvente større belastning end normalt?

/Niki

  • 0
  • 0
#36 Anonym

Vi kan alle begå fejl. Og det er derfor vi tester.

Ja, men i det her tilfælde tror jeg ikke der har været tale om decideret test.

Det virker ikke som om der udført tilstrækkelige performance-test af folketingets system i det her tilfælde. Når det samtidig går 'live' samme dag, som folketinget har åbningsdebat virker næsten overmodigt.

Jo, men det har åbenbart været tiltænkt, at 'live' skulle ske samtidig med folketingets åbning.

Fra: http://www.version2.dk/artikel/2096-ny-cms-loesning-skal-loefte-folketin...

forventes i drift samtidig med åbningen af Folketinget i oktober 2008

Se bort fra årstallet, men man har vel ligesom haft et år ekstra til netop at raffinere systemet.

MHT test, så vil jeg godt sætte en kasse øl på højkant i forhold til følgende postulater: - Der er [b]ikke[/b] lavet en ordentlig funktionsprøve, fordi: Hvis det havde været gjort, så ville man have opdaget det der latterlige med at skalere store billeder til thumbnails.

  • Der er [b]ikke[/b] lavet en availability prøver over 30 dage (subsidiært 20 arbejdsdage), fordi: Så ville disse søgebotter, som angiveligt skulle være et problem, forlængst have indexeret siderne, og dermed ikke udgøre et problem.

  • Der er [b]ikke[/b] lavet en svartidsprøve (subsidiært stresstest) fordi: Så havde man forlængst observeret, at systemet stod af i en sky af hestep....

Det undrer mig, efter et års forsinkelse, at man idriftsætter et utestet system, uagtet man skulle tro, at det forgangne år skulle have plads til test/kvalitetssikring osv..

  • 1
  • 0
#37 Nikolaj Brinch Jørgensen

Det kan da godt være at der ikke er udførst tests, og at man ved at have udført disse havde fundet og rettet de fejl der nu er. Det er dog ikke kernen i problemet. Det kan kun ses som symptombehandling, da det jo ikke er her hunden ligger begravet.

Man kan som bekendt ikke teste god kvalitet ind i et produkt, (en bil bliver ikke bedre kvalitet fordi den skal køre den dobbelte distance på testbanen), det har Toyota m.fl. lært os. Altså må man tilbage og spørge sig selv (5 * WHY), for at finde root cause, som ganske givet ligger i en for dårlig proces omkring udvikling, endsige, de meget snævre rammer der ligger i kontrakterne når man arbejde med IT for den offentlige sektor.

Så lad os nu en gang for alle finde root cause for alle disse problematiske offentlig projekter, uagtet hvem der er leverandør, hvilke produkter osv. der er involveret.

I dag er der 2 konktraktformer i IT verdenen (fast pris og timebaseret), begge har de en ting til fælles, den ene part bærer al risiko, og er næsten garanteret at blive taber, altså win/loose eller loose/win.

Lad os nu begynde at bruge nogle mere tidsvarende konktraktformer, så det lugter lidt mere af win/win.

Og så skal vi altså til at tage os sammen proces mæssigt - ligesom vi skal blive langt bedre til at finde ud af hvad ting koster.

  • 0
  • 0
#40 Anonym

Så lad os nu en gang for alle finde root cause for alle disse problematiske offentlig projekter

'root cause' er EU udbudsprocessen, som vi ikke lige kan ændre. så:

Lad os nu begynde at bruge nogle mere tidsvarende konktraktformer

ligger ikke lige om hjørnet.

@Gunnar:

Hvis man vil vinde kunden skal man være billigst - ikke bedst

Det kommer ganske an på hvilke udvælgelseskriterier, der er fremsat i udbudsbekendtgørelsen.

Jeg har f.eks. engang lavet kravspec'en til udbud af hosting af Navition Stat. Det der var tale om statens økonomisystemer med dertil hørende oplsninger/betalinger m.v. var 1. prioritet [b]sikkerheden[/b], og ikke prisen. Så uanset prisen, så ville man dumpe på sikkerheden, hvis den ikke var tilstrækkelig.

men tilbage til tests:

Det kan da godt være at der ikke er udførst tests....

Det er en lidt dårlig analogi du fremfører her.

I disse offentlige projekter, er der tale om indkøb af ubesete varer, alene baseret på funktionelle (og objektivt [b]målbare[/b]) krav.

Der er med andre ord ikke tale om at teste i den forstand, men at 'inspicere varen'.

Man kan ikke købe en 'Toyota', men et 'Transportmiddel', der skal opfylde nogle krav.

Hvis man har krævet, at dette 'transportmiddel' skal kunne køre 200 km/t, så er det naturligt, at efterprøve om det nu også kan det.

På samme måde, hvis dette 'transportmiddel' skal kunne transportere minimum 20 samtidige passagerer, så er det også naturligt at efterprøve det.

Core problemet er, at man allerede i kravspec'en definerer systemet, og det er det, det bliver givet bud på.

Ændringer undervejs vil naturligvis koste ekstra i det omfang ændringen ikke er forudset i kravspec'en.

Så 'it simply boils down to': For dårlige kravspec's og eller manglende 'inspicering af varen', som åbenbart er tilfældet i denne sag, med mindre der ikke har været krav.

Det er klart, at hvis der ikke har være krav om svartid, antal samtidige brugere, oppetid, minimalistisk javascript, CSS osv, så kan man ikke gøre gældende, at der er tale om en mangel.

Hmm.. - i skrivende stund er siden utilgængelig - hvilken undskyldning mon man vil bruge denne gang?

  • 0
  • 0
#41 Anonym

Interessant, at man skal have minuspoint for at beskrive den virkelige verden.

Men jeg tillod mig lige at montere en monitor med 1/2 times interval, og her er resultatet: [pre] MonitorLogsId(INT);MonitorURIsId(INT);TickId(FLOAT);TickSubId(INT);StartTime(FLOAT);StartTick(FLOAT);EndTick(FLOAT);NumberTicks(FLOAT);StatusCode(INT);StatusString(TEXT);NumberOfThreads(INT);ConnectTime(FLOAT);FirstToLast(FLOAT) 1;1;1380094200.37702;10001;40100.372044;1380094200.97103;1380104256.3132;10055.342173;10110;;1;55.108491;9999.669997 2;1;1380135277.08059;10001;40100.37252;1380135277.65976;1380145335.08;10057.420235;10110;;1;55.986869;10000.739242 3;1;1381935293.7528;10001;40100.393353;1381935294.2432;1381935475.07331;180.830103;200;OK;1;49.426882;43.490836 4;1;1383735298.19164;10001;40100.414187;1383735298.69203;1383735439.47508;140.783055;500;Internal Server Error;1;49.35551;36.62147 5;1;1385535306.71847;10001;40100.43502;1385535307.21109;1385535488.09678;180.885693;200;OK;1;49.100672;46.200528 6;1;1387335311.28887;10001;40100.455854;1387335311.77938;1387335500.63887;188.859483;200;OK;1;54.902034;47.665443 [/pre] Jeg har ikke til hensigt at komme med forklaringer på indholdet, da der tilsyneladende ikke er det fornødne kendskab til 'tingenes tilstand', men jeg går ud fra, at man i det mindste ved, at 200 OK er essentielt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Webinars and Whitepapersopen_in_new
Webinar
Webinar
ctrlX AUTOMATION - Automation like a Smartphone
Whitepaper
Whitepaper
Fra device data til smart information
Webinar
Webinar
IT Company Rank Insights Seminar
Se flereopen_in_new
Jobfinder Logo
Upload dit CV
Få nye job via e-mail
Upload din jobannonce
Job fra Jobfinder