Leverandør undgår skideballe efter gumpetung start for folketinget.dk

Det nye folketinget.dk havde i sidste uge svære problemer med at betjene brugerne af sitet i kølvandet på lanceringen. Det skyldtes blandt andet thumbnails på fem-seks megabyte, men leverandøren slipper for hug fra kunden.

To gange efter lanceringen af Folketingets nye hjemmeside tirsdag i sidste uge måtte brugerne døje med lange svartider og beskeder om, at siden ikke var tilgængelig.

Men selvom problemerne delvist kan tilskrives en regulær brøler fra leverandøren, konsulenthuset Addition, holder Folketingets it-udviklingschef hånden over leverandøren og bedyrer overfor Version2, at Addition har gjort sit arbejde godt nok.

Det nye folketinget.dk er baseret på et CMS fra Sitecore, og det gik i luften tirsdag den 6. oktober klokken 12 samtidig med åbningen af det nye folketingsår. Men webserverne bag den funklende nye hjemmeside blev hurtigt tvunget i knæ i løbet af tirsdag eftermiddag.

Det skyldtes ikke kun interesserede brugere, men også et hold på fire nysgerrige søgemaskinerobotter, som efter lanceringen gik i gang med at kravle henover hjemmesiden for at indeksere nyt og gammelt indhold.

Robotternes søgeiver faldt også sammen med den ugentlige 'beskydning' af hjemmesiden, som Folketinget har hyret et eksternt firma til at gennemføre på et tilfældigt tidspunkt i løbet af ugen for at sikkerhedsteste siden. Også dét tog på servernes kræfter.

Torsdag var den så gal igen, fordi thumbnails af billeder af folketingspolitikere ikke var blevet nedskaleret inden visning i browseren. Mange af hjemmesidens thumbnails var derfor store filer på fem-seks megabyte, som blot blev nedskaleret af brugerens browser.

Thumbnail-problemet er nu bragt i orden af Addition, og det har ifølge it-udviklingschef i Folketinget, Liselotte Astrup, løst det største problem med hjemmesidens manglende svarvillighed.

»Hjemmesiden kører nu, som den skal, og det virker som om, at billedskaleringsproblemet virkelig har løst problemerne,« siger Liselotte Astrup.

Leverandør klapper i
Version2 ville gerne have hørt en forklaring på problemerne med nedetid og lange svartider fra leverandøren selv, men Addition har efter aftale med kunden lukket munden med syv segl.

It-udviklingschef i Folketinget, Liselotte Astrup, erkender dog over for Version2, at Addition burde have forhindret thumbnails i megabyte-størrelse i at trække servernes ydeevne ned.

Hvilke performancetests gennemførte I af folketinget.dk inden lancering?

»Vi testede hjemmesiden med 500 samtidige brugere, hvilket er over gennemsnittet for besøgende på siden,« siger Liselotte Astrup.

Har der været gennemført tests for at afprøve scenariet med søgemaskinerobotterne?

»Mig bekendt har vi ikke testet specielt for søgerobotterne, og det havde heller ikke givet problemer for os, hvis søgerobotterne bare havde crawlet det nye indhold på sitet. Men der har været en masse gamle links, der ikke længere virkede, og som robotterne har brugt uforholdsmæssigt meget serverkraft ved at forespørge på,« siger Liselotte Astrup.

Har leveret varen
Hun fortæller samtidig, at Folketinget ikke har nogen interesse i at skyde skylden for problemerne på leverandøren.

Men synes du, at Addition har gjort sit arbejde godt nok?

»Jeg har aldrig oplevet en leverandør, hvor alt bare er gået som smurt, og vi synes, at Addition har leveret varen på trods af de driftsproblemer, der har været,« siger Liselotte Astrup.

Men burde det ikke have været sikret inden lancering at thumbnails af billeder på folketinget.dk ikke kunne fylde flere megabyte?

»Jeg kunne godt have ønsket mig, at Addition havde fortalt os, at det kunne give et performance-problem. Og Addition har også indrømmet, at man skulle have løst det på forhånd.«

Burde I have bedt det eksterne sikkerhedsfirma om at lægge 'beskydningen' af folketinget.dk på et andet tidspunkt, så det ikke faldt sammen med lanceringen af hjemmesiden?

»Det var rigtigt dumt, at det lige skulle falde på samme tidspunkt. Og vi kunne måske have sagt til dem, om de ikke ville lade være med at skyde på os tirsdag efter klokken 12. Men egentlig var det fint nok, at de gjorde det samtidig, for det var medvirkende til at gøre opmærksom på problemerne på hjemmesiden.«

Hvad gør I fremadrettet for at sikre, at folketinget.dk ikke fortsat oplever de samme problemer?

»Vi har nu løst de problemer, vi har identificeret. Og så overvåger vi systemet i døgndrift og overvejer nu, om vi skal lade sitet gennemgå en ekstra analyse af, om det er muligt at optimere det på ydelsen,« siger Liselotte Astrup.

Hjemmesiden var oprindeligt planlagt til at gå i luften ved Folketingets åbning i oktober sidste år. Men et nyt ESDH-system (dokumenthåndteringssystem) gjorde det nødvendigt at udvikle en webservice til at binde CMS'et sammen med ESDH-systemet, og det har været medvirkende til forsinkelsen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

Hvilke performancetests gennemførte I af folketinget.dk inden lancering?

»Vi testede hjemmesiden med 500 samtidige brugere, hvilket er over gennemsnittet for besøgende på siden,« siger Liselotte Astrup.

Her har jeg prøvet at redegøre for[1] hvordan man tester 500 'samtidige' brugere, hvilket jeg på ingen måde tror er tilfældet mht. folketinget.dk.

[1] Under en af artiklerne, eller også under PHK's artikel om webcaching.

Bemærk [b]samtidige[/b] er et diffust begreb, og hvis man har krævet f.eks. 1 sek responsetid, så medfører det 500 req/sek, hvilket svarer til 1.800.000 req/time eller 14.400.000 req/8 timer (arbejdsdag).

Jeg tvivler stærkt på, at denne prøve skulle være udført, men det kan let modbevises ved at offentliggøre en rapport.

Hun fortæller samtidig, at Folketinget ikke har nogen interesse i at skyde skylden for problemerne på leverandøren.

Naturligt nok, for hvis man ikke har lavet en ordentlig kravspec/sla, så der der ikke noget at komme efter hos leverandøren.

  • 0
  • 0
Anonym

Der er noget, der tyder på, at man har fået kuglerne op i ganghøjde, svartidsprøve i dag:

Start probe @ ms: 1216179252.05755
Start connect @ ms: 1216179252.39963 - deviation = 0.34208083152771
End connect @ ms: 1216179300.55215 - deviation = 48.152517080307
Last byte sent @ ms: 1216179300.84854 - deviation = 0.296390056610107
First byte received @ ms: 1216179344.18263 - deviation = 43.3340940475464
Probe end @ ms: 1216179427.55205 - deviation = 83.3694159984589

Probe total ms: 175.49449801445

Probe received bytes = 19679 @ 200 - OK

Altså ~43 ms svartid.

Jeg har ikke rigtig nogen dokumentation, men jeg mener at man i sidste uge lå på 1.500 ms+ for forsiden alene.

Men hvis man har fået kuglerne op i ganghøjde, syens jeg det er OK - bortset fra det skulle have været gjort inden lanceringen (så undgår man dårlig presseomtale/brugeroplevelse).

  • 0
  • 0
Michael Madsen

Jeg er personligt ikke imponeret, øverest i højre side kan man se Vis dokumentkurv(0).
Jeg har endnu ikke fundet ud af hvad man kan købe eller få der fra :O

Jeg kom også til at kikke lidt i kildekoden og den er ikke ligefrem sat ordligt op, men ligner bare noget "rodet butik"

Efter min mening kunne det gøres bedre, jeg synes også siden er langsom endnu.

  • 0
  • 0
Hans-Michael Varbæk

Nu skal jeg nok lade være med at kommentere på nogle specifikke problemer men..

Men der har været en masse gamle links, der ikke længere virkede, og som robotterne har brugt uforholdsmæssigt meget serverkraft ved at forespørge på

Det er derfor at man f.eks. bruger ".htaccess" til at lave "HTTP 302 Redirected" på tidligere links som er blevet flyttet. Nu bruger serveren så sikkert IIS'en så det er jo en anden historie, men det er almen viden for de fleste web-administratorer at hvis man har flyttet et link/dokument, så laver man en 302 til det nye sted hvis man gerne vil fortsat være gode venner med Google og de andre søgemaskiner :-)

  • 0
  • 0
Thomas Schmidt

Det er derfor at man f.eks. bruger ".htaccess" til at lave "HTTP 302 Redirected" på tidligere links som er blevet flyttet.

Nej det gør man så ikke, medmindre man vil have at søgerobotterne besøger den samme gamle url igen og igen. Hvis det skal laves rigtigt(f.eks. SEO mæssigt) skal der bruges 301.

Tror i øvrigt også de fleste er rykket videre fra den oldnordiske .htaccess måde at styre redirects og den slags på.

  • 0
  • 0
Jesper Louis Andersen

Lige en af mine pet-peeves, nu vi er igang: Når man laver test af webservere bør man også se på begrebet varians. Du kan jo sagtens have et par få requests som klarer sig absolut elendigt selv om flertallet af dine requests går rimeligt hurtigt. Variansen, eller bedre endnu, et histogram viser temmeligt hurtigt om det kunne være et problem.

Endnu mere vigtigt, så skal man ikke bero på middelværdien alene. Den siger i bedste fald meget lidt og i værste fald det forkerte.

  • 0
  • 0
Hans-Michael Varbæk

Nej det gør man så ikke, medmindre man vil have at søgerobotterne besøger den samme gamle url igen og igen. Hvis det skal laves rigtigt(f.eks. SEO mæssigt) skal der bruges 301.

Du har sku ret, jeg glemte lige at dobbelt-tjekke at det var 301 og ikke 302 :-)

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