Ukendt flaskehals driller: Forskudsopgørelser tvinger skats servere i knæ
Skats servere har i løbet af dagen været nær ved at brænde sammen under presset fra nysgerrige borgere, der ville ind at kigge på forskudsopgørelsen for næste år, som nu er tilgængelig i skattemappen.
Og dét selvom Skat på forhånd havde firedoblet serverkapaciteten i forhold til sidste år.
»Der er rigtig meget tryk på, og vi må også erkende, at vi har vanskeligheder med at leve op til det niveau af håndtering af besøgende, vi havde forventet,« siger kontorchef i Skats it-afdeling, Søren Kjær.
Ifølge Søren Kjær har de besøgende formiddagen igennem måttet døje med svartider på flere minutter, uanset om man endte med at komme igennem til forskudsopgørelsen, eller blot blev spist af med et 'Der er travlt på TastSelv i øjeblikket. Prøv igen senere'.
Svartiderne ser bedre ud nu, men mange brugere oplever stadig at blive henvist til køen, fortæller Søren Kjær.
»Vi arbejder i øjeblikket på at få stabiliseret situationen. Vi har et højt visningsniveau, men vi må også konstatere, at mange oplever lange svartider. Indtil klokken halv tolv i dag har vi vist 104.000 forskudsopgørelser. Til sammenligning viste vi 166.000 i løbet af hele den første dag sidste år,« siger Søren Kjær.
Havde ventet ekstra travlhed Skat havde på forhånd ventet travlhed i køen til webserverne bag hjemmesiden.
Et farvel til mellemskatten og en forhøjet grænse for, hvornår man skal betale topskat, er blandt de ændringer, som man havde forudset ville give ekstra trafik.
Derfor havde Skat også firedoblet serverkapaciteten sammenlignet med sidste år, så systemet nu kan håndtere i omegnen af 45.000 brugere i timen.
Det fik dog ikke Søren Kjær til at garantere nul ventetid, da Version2 talte med ham mandag, hvilket også ville være faldet uheldigt ud dagens forløb taget i betragtning.
Ifølge Søren Kjær arbejder leverandøren KMD lige nu med at finde frem til de flaskehalse i systemet, der er skyld i afvisningen af brugerne.
Mens fejlfindingen skrider frem, sættes der en dæmper på servernes arbejdsindsats.
»Vi har midlertidigt skruet ned for kapaciteten for at kunne gennemskue, hvor flaskehalsene opstår. Og så skruer vi stille og roligt op igen og sikrer samtidig, at vi løbende har fornuftige svartider. Vi håber, vi dermed kan få afdækket problemet med flaskehalsene,« siger Søren Kjær.
I har forsøgt at sikre en fornuftig serverkapacitet på forhånd, men der har alligevel været svartider på flere minutter. Hvad vil I gøre for at sikre jer, at det ikke sker igen næste år?
»Vi skal lære af det her, og det er også derfor, at jeg nu afventer en redegørelse fra leverandøren for, hvor det er vi møder flaskehalsene. Det ved vi ikke endnu,« siger Søren Kjær.
Søren Kjær forventer, at mange besøgende fortsat vil blive mødt med beskeden om travlhed på linjen frem til ved 17-tiden, hvorefter belastningen gerne skulle aftage.
Kommentarer (13)
... så skulle forskuds-applikationen være udviklet i vb6 og asp, hvilket måske kan forklare skalerings-problematikken. Er der nogen der ved om jeg husker forkert?
-
0 -
0
Endelsen lyder på .aspx. I øvrigt ville der nok have været tale om VBScript, og ikke VB6. VB6 er et pseudokompileret sprog, der ikke understøtter multithreading og normalt heller ikke anvendtes til web-applikationer (selv om MS faktisk forsøgte sig med et modul til udvikling af webservice-dll'er til IIS - det var et mareridt at fejlfinde på, og performede sandsynligvis ringe).
Da forskudsregistreringerne er genereret i løbet af de sidste par dage, burde det være en smal sag at skalere systemet til mange samtidige brugere. Ville Varnish have hjulpet her, eller giver Varnish kun en fordel hvis mange brugere forsøger at tilgå de samme statiske filer?
-
0
-
0
Ville Varnish have hjulpet her, eller giver Varnish kun en fordel hvis mange brugere forsøger at tilgå de _samme_ statiske filer?
Varnish vil næppe have en stor betydning - for som du er inde på, vil det ikke være de samme dokumenter, som tilgås af forskellige brugere.
I denne situation er der mange brugere, som hver især skal tilgå deres specifikke indhold igennem en krypteret forbindelse med masser af adgangstjek.
Jeg tror ikke det vil have gjort megen forskel, om så sitet VAR lavet med ASP og VBScript og serveret igennem Varnish - adgangstjek og indhentning af personificeret indhold vil skulle foretages for hver bruger alligevel.
(disclaimer: Jeg forholder mig ikke til, om Varnish er bedre end f.eks. Apache eller IIS til at håndtere mange forbindelser, men udtaler mig om, hvorvidt en cache vil kunne gøre en stor forskel)
(disclaimer2: Med meget store mængder trafik vil selv små ting naturligvis kunne blive store problemer - men jeg tvivler på at cache, webserver eller programmeringssprog har voldsom betydning set i forhold til kryptering, SSL, adgangstjek osv.)
-
0
-
0
Problemet her lader jo til at være datakapicitet, udover mulige problemer med selve programmeringen.
Men da SKATs sider often kun bliver spidsbelastet op til bestemte tidspunkter på året, var det måske en ide med en cloud løsning som kunne skaleres op og ned.
-
0
-
0
- november må de, der er født den 1. gå ind
- november må de, der er født den 2. gå ind
osv.
-
0
-
0
Jeg vil nødig se skatteoplysninger mm. forsvinde i en tilfældig sky.
Staten kunne have sin egen sky, men jeg tvivler på det er rentabelt. Det er trodsalt få dage/timer om året det er nødvendigt.
-
0
-
0
"Endelsen lyder på .aspx"
Prøv at tage en vilkårlig *.asp fil og omdøb den til *.aspx, kald den og se hvad der sker ...
... men ja, det peger på en ASP.Net løsning.
-
0
-
0
Indledningsvis ved vi ikke hvad der ligger bag denne udtalelse
Og dét selvom Skat på forhånd havde firedoblet serverkapaciteten i forhold til sidste år.
Det nytter ikke noget at 4-doble frontend kapaciteten, hvis de bagvedliggende systemer ikke kan følge med.
Hvis flaskehalsen er en bagvedliggende database server, så kan man smide nok så mange frontends på, uden det hjælper en skid.
Endvidere er der Garbage Collectoren i .NET, der har det med at brække sig ved hård belastning.
Her er der også forskel på om en 4-dobling er 4 servere i load-balancing, eller 1 server, der er 4 gange så kraftig.
Hvis det kun er een server der er 4 x kraftigere, så 4-dobler man sådan set GC problemet.
Blot nogle generelle betragtninger, da vi ikke kender den bagvedliggende infrastruktur (og kodening).
-
0
-
0
En ukendt flaskehals
Tyder på manglende viden om performance i 'økosystemerne' - hvis det reelt er 'ukendt'.
-
0
-
0
Endvidere er der Garbage Collectoren i .NET, der har det med at brække sig ved hård belastning.
Sammenlignet med hvad? Mine erfaringer siger mig den er mere performant end f.eks. javas gc i mange tilfælde for slet ikke at tale om Rubys som er sløv som bare f... når der bliver rigtigt travlt. Har personligt selv driftet end .net baseret løsning som uden problemer kunne håndtere et par tusinde requests i sekundet per server.
Du kan smadre GC performance på en hvilken som helst platform hvis der er elendigt optimeret kode bagved. Desværre en af problemerne ved denne GC elskende verden, udviklerne tænker ikke så meget over hvornår de skal frigive objekter osv :)
-
0
-
0
[quote]Du kan smadre GC performance på en hvilken som helst platform hvis der er elendigt optimeret kode bagved.[quote]
Ja, men er formålet med GC ikke netop at tilgodese de slamkodere, der ikke har styr på deres memory (de)allokering?
-
0
-
0
Det foresvæver mig, at disse 'peak interest' har været oppe før, og vil nok komme det igen.
Min gamle lærermester sagde, at man ikke skal kaste med æbler hvis man selv er et skrog.
Så det nytter ikke at kritisere forholdende uden at komme med et konstruktivt forslag.
Det kommer hermed:
Forskudsopgørelser er jo ikke noget realtids komponeret 'noget', men kan generes i god tid som statiske filer.
Hvis man indledningsvis har mulighed for at registrere noget 'salt' i forbindelse med andre oplysninger, så kommer her et forslag til løsning af peak-level requests.
Forudsætning:
Generer disse statiske sider ud fra eks. en MD5 af CPR+Navn+'salt'.Lav en simpel forespørgelsesside med de basale oplysninger, eksempel her:
http://w-o-p-r.dk/test/forskud.1.aspUd fra de angivne oplysninger, så lave en redirect til den aktuelle fil med oplysningerne.
Det kan afprøves, men i dette tilfælde er det:
e84c4fa383c82c2cc51581c0b9d5c8a3.html
Netop ved at forgenerere statiske filer kan man opnå et væsentligt højere performanceniveau end at generere dem dynamisk.
I det koncept er der ingen grund til at køre krypteret, med mindre man mener at det er udbredt at lave evesdropping, på f.eks. fiber.
Min lille hjemmestrikede server kan sagtens sustaine 10 samtidige req/sek på en PII 200MHz,så det burde ikke være noget som helst problem at servicere mange - mange flere req/sek på moderne HW.
Altså budskabet er:
Lav en (prægenereret) 'shortcut' til forskudsopgørelser, årsopgørelser og lign, når man ved behovet opstår.
-
0
-
0
Og nøjs evt med at prægenerere alle dem, der var inde på siden sidste år. De fleste af dem kommer nok også i år og de fleste af de andre kommer nok heller ikke i år.
-
0
-
0
