Søgerobotter kvalte Folketingets nye hjemmeside

Fire søgerobotter havde travlt med at indeksere hele den nye hjemmeside, og det var nok til at give brugerne lange svartider kort efter premieren på det nye Folketinget.dk.

Folketingets nye hjemmeside gik i luften tirsdag klokken 12 samtidig med åbningen af det nye folketingsår. Og gik kort derefter ned.

I flere perioder tirsdag eftermiddag oplevede brugerne lange svartider eller fik at vide, at siden ikke var tilgængelig. Det skyldtes en uventet overbelastning af webserverne.

Vel at mærke ikke kun fra nysgerrige borgere, som ville se den nye hjemmeside, men også fra internettets søgerobotter.

»Vi er inde og kigge på det og kan se, at der er fire søgerobotter inde og crawle hele sitet,« siger it-udviklingschef i Folketinget, Liselotte Astrup.

Ud over at indeksere alt det nye indhold og de nye links, så følger robotterne også de gamle links, de allerede har liggende. Det lægger en belastning på serverne, som ikke var forventet på baggrund af de tests, som Folketinget og leverandøren Addition havde kørt inden lanceringen.

For at få hjemmesiden til at svare normalt har it-folkene været nødt til at gå ind og lukke de sessioner, som søgerobotterne har startet.

Folketinget.dk er udviklet med en løsning til webcaching for at lette trykket på serverne, men cachen blev slået fra i forbindelse med, at hjemmesiden gik live tirsdag.

En del af problemet er ifølge Liselotte Astrup, at Folketingets hjemmeside indeholder et stort antal meget store dokumenter, som giver problemer, når de bliver gennemtrawlet af en søgerobot første gang.

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

Jamen svarer det ikke sådan ca. til 4 brugere? Det burde da ikke kunne lægge nogen site ned.

Jeg kan i øvrigt anbefale den extension til Firefox, der hedder page speed.

Den fortæller en masse ting, herunder at forsiden alene består af 85 'resources' på ialt 873,2 KB, hvor intet er gzip'et.

873 KB!? - det er sq meget godt klaret for en simpel forside, og det er ikke grafikken, der fylder mest.

Nåh - men båndbredde må de jo have nok af.

  • 0
  • 0
#2 Lars Malmgren

Ha ha!

En forside på 873 kb, det er jo sindsygt! Og 4 søgerobotter, der hente nogle få sider samtidigt får det til at gå i sort.

Jamen hvad i al verden gør de så, når de rigtige brugere går i gang med at læse???

Uanset om man har store dokumenter, så bør man da skalere web-siden til at kunne klare det antal samtidige brugere man forventer + en ekstra margin. Og det er vel mere end 4 ;)

Nå men jeg fik da et godt grin. Held og lykke med det!

  • 0
  • 0
#3 Jesper Jarlskov

Man kunne vel forestille sig automatiserede processor med en bunke links i kø arbejder en tand hurtigere end almindelige brugere der også skal bruge tid på at læse og forstå indholdet inden de bevæger sig videre.

Men stadig, 873kb lyder godt nok af meget, og man skulle næsten tro at 4 robotter skulle kunne håndteres!

  • 0
  • 0
#4 Jens Skov

Ja, 4 brugere lyder ikke af meget. Men det er ikke antallet af "brugere" der er interessant i denne sammenhæng, men antallet af requests (transaktioner), som der bliver udført fra brugerene. "Normal" browsning medfører typisk at man henter de (mange) elementer der findes på én side, og at man så ellers forholder sig i ro, inden man klikker videre, og dermed sender en ny samling requests.

Problemet her er at de 4 robotter er istand til hver at have f.eks. 50-100 forbindelser samtidigt i deres gennemtrevling at et website. Og det stopper måske ikke engang dér. Visse hensynsløse robotter (crawlere) har ikke nogen øvre grænse og fyrer derfor requests afsted i en uendelighed. Dette sluger ganske simpelt al båndbredden fra serveren, som så ikke kan levere data.

Webchacing kan delvist løse dette problem, idet webserveren (systemet) ikke skal bruge megen tid på at svare, men blot sende. Et uforholdsvist stort antal requests vil dog stadig give problemer.

Problemet svarer lidt til om man skal lave 16-sporet motorvej på Køge-bugt (eller andre steder), for altid at kunne undgå kø, eller man vælger at acceptere lidt kø engang imellem.

Folketinget.dk burde måske have været forudsigende nok til at spærre for kendte robotter lige ved opstart og så åbne for dem på et senere tidspunkt. Min erfaring er at det kan være vanskeligt at finde dem alle proaktivt inden der sker noget.

Læs forøvrigt også PHK's glimrende Blog om Fokus på Web-Caching http://www.version2.dk/artikel/12393-fokus-paa-web-caching

  • 0
  • 0
#5 Anders Gregersen

Størrelsen afhænger bl.a. hvilken platform det er baseret på og hvilken funktionalitet og support af browsere etc. At forsiden har en given størrelse kan give problemer, men hvis mange af elementerne genbruges på andre underliggende sider så skal de alligevel hentes på et tidspunkt.

Det er da rigtig at man vha optimering m.m. sagtens kan reducere størrelsen, men det er på bekostning af noget andet.

4 søgebotter kan næppe sammenlignes med 4 personer. De benytter flere tråde og kan sagtens ligge en webserver i knæ. Selv med loadbalancere foran sker det tit at alle requests redirectes til samme webserver fordi det opfattes som en session.

  • 0
  • 0
#6 Hans-Kristian Bjerregaard

Nu opfører søgerobotter (specielt fra google) sig normalt rigtigt pænt så jeg forstår ikke at det overhoved kan være et problem. En website er jo på ingen måde en særlig tung beregning.

F.eks. kan Dell's billigste rackserver (til små 5000+ kr) snildt køre et website med 20.000+ daglige besøgende uden at nogen få sved på panden af det.

Min eneste tolkning er at siden er mere end almindeligt slamkodet. Jeg er faktisk imponeret over at man kan skrive kode der er så tungt.

(beklager reklamen for dell men det var lige et eksempel jeg havde ved hånden)

  • 0
  • 0
#7 Brian Jacobsen

Nu har jeg ikke detaljeret kendskab til denne sag, men jeg ved af egen erfaring, at specielt den statsstøttede danske crawler netarkivet.dk ikke opfører sig specielt pænt. Jeg måtte blokere for den, da den ikke respekterede min robots.txt fil og stjal al min båndbredde.

Det kunne da være lidt morsomt, hvis det er den, der er på spil...

Læs netarkivets egen begrundelse her:

http://netarkivet.dk/faq/index-da.php#faq_robots

  • 0
  • 0
#8 Nicolai Schlenzig

Husker også hvordan netop Netarkivet (Stats-ejet) mente at deres crawlers skulle "høste" en af mine sider inkl. alle undersider.

Dette resulterede i ca. 1 GB trafik på 2-3 timer (mener jeg). Set i lyset af, at en normal bruger kun henter 1-10 MB om dagen, så synes jeg også det var i overkanten.

Til sammenligning kan jeg sige, at Google bots kun hentede op til 300 MB om dagen i sammen periode.

Men for at komme tilbage til tråden, så jeg slet ikke se, at det skulle give årsag til lange svartider, at der var 1 eller 4 bots inde og crawle siderne.

Hvis de virkelig har så mange dokumenter i arkivet (online) så vil jeg håbe og ikke mindst FORVENTE, at disse ligger på et helt andet cluster, så forsiden og alle de nye smarte sider ikke mærker en hyperaktiv robot.

De kunne nok have valgt rigtig mange løsninger, for at komme omtalte problem til livs. Men set ud fra deres egne forklaring og kommentarer her og på andre fora, så har de tydeligvist ikke gjort meget, hvis noget, for at komme problemerne i forkøbet.

Jeg kunne f.eks. nævne: proxy/caching, CDN (Content Delivery Network), generel optimering, robots.txt (hvis det er ønskværdigt), bare for at nævne et par...

Det kan også godt være de har researced lidt - det kan man kun formode, men så ville det måske klæde dem at komme med en lidt mere dybdegående udtalelse om problemet, og hvad de har gjort proaktivt og ikke mindst efter problemer "lagde" deres side ned.

  • 0
  • 0
#9 Anonym

Problemet her er at de 4 robotter er istand til hver at have f.eks. 50-100 forbindelser samtidigt i deres gennemtrevling at et website.

Ja, er [b]istand til[/b], men Google,Yahoo samt MSN, som lige var de første jeg tænkte på, gør det ikke, snarere tværtimod. De opfører sig pænt.

Er det derimod diverse (ondsindede) harvestere, er det en anden snak.

Nu skrev jeg at det svarede til 4 brugere, men i virkeligheden vil 4 brugere belaste mere, da browserne henter alle de mange mange .js og .css filer (samtidigt).

Dog har wininet, som IE bruger, vistnok en grænse på 5 samtidige requests.

Det kunne være interessant at få oplyst hvilke søgerobotter, der opfører sig så aggressivt, så man kan spærre for dem.

  • 0
  • 0
#10 Anonym

Det kunne være interessant at få oplyst hvilke søgerobotter, der opfører sig så aggressivt, så man kan spærre for dem.

Så lige ovre hos konkollegaen:

http://www.computerworld.dk/art/53359?cid=10&a=cid&i=10&o=6&pos=7

Hun fortæller, at Folketinget udmærket kan se, hvor de tusindvis af besøg stammer fra. Hun vil dog ikke fortælle hvorfra.

"Vi kan godt se det, men det vil vi helst ikke udtale os om, er vi blevet enige om," siger Liselotte Astrup.

Så det med at dele viden (if any) kan åbenbart skyde en hvid pind efter, så andre kan opleve samme problem i fremtiden.

God taktik !?

  • 0
  • 0
#11 Hans-Kristian Bjerregaard

Hvorfor er det så pinligt en side går ned første dag? Alle ved jo at der er urealistisk store mængder af trafik da alle skal ind og lige se siden.

Jeg skulle jo også selvom jeg aldrig bruger den!

Hvorfor er det at man altid lige skal stikke en lille løgn istedet for at sige at man kun gider bruge recourcer til det besøgstal siden normalt får. Det er der jo ingen der kan have noget imod!

Eller det er der sikkert man du skal være ret oppetidsfacist hvis du vil kræve at et site kan levere (n*100)% over normalniveau. Det er kun en ganske lille mængde sites der skal kunne dette og folketinget.dk er bestemt ikke en af dem.

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Hvorfor er det så pinligt en side går ned første dag?

  1. Fordi det giver de ny brugere et dårligt indtryk fra starten.

  2. Fordi der ikke er nogen der siger at den første dag er den største traffik du kommer ud for. Slet ikke for folketing.dk.

  3. Fordi det er amatøragtigt ikke at have testet spidsbelastninger.

  4. Fordi det er amatøragtigt i det hele taget ?

Poul-Henning

  • 0
  • 0
#13 Michael Friis

Nu nævner de godt nok at der er tale om robotter fra "Internationale Søgefirmaer" (tænd sirenen), men der kunne jo også være tale om lokale custom-robotter der trawler politisk info. Hvemstemmerhvad.dk har f.eks. en, Kaas & Mulvad har vist også en og jeg har lavet en til folketsting.dk (som jeg dog endnu ikke har sluppet løs på det nye site -- "det var ikke mig!")

Det "fede" ved det gamle site var, at det statisk genereret og derfor kunne serve request ekstremt hurtigt. Med en phat pipe og en aggresivt multitrådet scraper, kunne jeg hente al data fra alle samlinger tilbage til 2004 på omkring et kvarter. Scraperen til det nye site er ikke komplet endnu, men det kommer nok ikke til at gå helt så hurtigt...

  • 0
  • 0
#14 Rene Madsen

Eller måske en overloaded MS IIS? Måske en overloaded MSSQL?

Under alle omstændigheder, så er det pinligt at 4 robotter uanset deres brug af sitet kan lægge folketingest hjemmeside ned.

Hvis man kigger på http://folketinget.dk/dokumenter/tingdok.aspx?/samling/20091/redegoerels... så virker det helt tåbeligt at det skal tage over 7 sekunder at hente et statisk dokument.

Hvis de har en form for caching, så er mit spørgsmål - hvorfor har de ikke varmet cachen op inden de søsatte siden? Evt. varmet caching op på SQL serveren...

Responsetider på over 1 minut virker amatøragtigt i min verden når det er noget så stort og professionelt.

  • 0
  • 0
#15 Anonym

Hvorfor er det så pinligt en side går ned første dag?

Det er ikke pinligt i sig selv, men af give 'søgebotterne' skylden er særdeles pinligt.

Hvis du kigger på f.eks. Google eller Yahoo, så har man muligheden for at eksponere et sitemap.

Dette sitemap igangsætter en søgning, men ikke multiple requests, og slet ikke på anfordring.

Havde man f.eks. eksponeret en sitemap, og eraf følgende indexering i god tid, så er jeg sikker på, at hverken Google, Yahoo eller MSN ville øve 'voldtægt'.

'Man' skriver også, at 'man' har taget hensyn til robots.txt, men herfra så giver: http://folketinget.dk/robots.txt en 404: "The page cannot be found" Ergo har man end ikke forsøgt at lægge en robots.txt fil, eller også har man fjernet den (uvist af hvilken årsag).

En forespørgsel på sitemap.xml (som er anbefalet af Google,Yahoo,MSN m.fl): http://folketinget.dk/sitemap.xml giver heller intet resultat, så: God latin er ikke overholdt.

Og

hvis du vil kræve at et site kan levere (n*100)% over normalniveau

Nej - ting hænger sammen - hvis man til enhver tid kræver 200% overkapacitet, så er det 200% dyrere i driftsomkostninger(måske).

I øvrigt er jeg fuldstændig enig i PHK's 4 punkter, måske med særlig vægt på pkt. 3 og 4.

  • 0
  • 0
#16 Jesper Hvirring Henriksen

Som der står i artiklen: "For at få hjemmesiden til at svare normalt har it-folkene været nødt til at gå ind og lukke de sessioner, som søgerobotterne har startet."

Man opretter altså ikke sessioner til robotter, for de sender ikke sessions cookierne tilbage og dermed bliver der oprettet en ny session på serveren for hvert enkelt request. Det burde "it-folkene" vide.

  • 0
  • 0
#17 Morten Winther

Synes efterhånden at de bots sluger mere og mere trafik på min side.

Det er da lidt vildt at de står for 20 procent af alle hits.

12.62%  Googlebot/2.1  
 3.63%  Yahoo! Slurp/3.0  
 2.92%  Jyxobot/1  
 1.34%  Sosospider+(+http://help.soso.com/webspider.htm)  
  0.83%  msnbot/2.0b (+http://search.msn.com/msnbot.htm)  
  0.44%  DotBot/1.1  
  0.25%  Yahoo! Slurp  
  0.22%  msnbot/1.1 (+http://search.msn.com/msnbot.htm)  
   0.13%  Opera 8.5  
   0.10%  Java/1.6.0_11  
   0.10%  +Zookabot/1.0  
   0.07%  Speedy Spider (http://www.entireweb.com/about/search_tech/speedy_spider/)  
   0.06%  Googlebot-Image/1.0  
   0.05%  OOZBOT/0.20 ( http://www.setooz.com/oozbot.html ; agentname at setooz dot_com ) 
  • 0
  • 0
#19 Nicolai Schlenzig

Man opretter altså ikke sessioner til robotter, for de sender ikke sessions cookierne tilbage og dermed bliver der oprettet en ny session på serveren for hvert enkelt request. Det burde "it-folkene" vide.

Det kommer vel helt og aldeles an på hvilket framework man benytter?

Jeg vil umiddelbart tro, at langt de fleste frameworks, der genererer sessions automatisk, ikke vil skelne mellem robotter og ikke-robotter, når der udtages en ny session (ID).

Det kræver vel en blacklist af User Agents, hvis man vil undgå at spilde ressourcer på robotterne?

Ikke desto mindre er det en rigtig god pointe, at man slet ikke bør spilde tid og ressourcer på session (data) behandling mht. robots/crawlers.

Jeg vil skrive det bag øret, og checke det ved næste kærkommen lejlighed :)

  • 0
  • 0
#20 Anonym

Som der står i artiklen: "For at få hjemmesiden til at svare normalt har it-folkene været nødt til at gå ind og lukke de sessioner, som søgerobotterne har startet."

Sessions og performance?

Bortset fra, at .NET formentlig 'autoopretter' sessions ved en ny request, så burde det vel ikke betyde ret meget for performance.

'Sessions' er jo sådan set bare en placeholder for eventuelle data, der kan ligge memory resident, i filer, eller i databaser.

Men det implicerer 'kun' et memory problem, hvis det altså er memory resident i IIS/.NET

Hvis vi antager, at en 'tom' session udtager eks. 128 bytes initielt, vil 1000 (ubrugte) sessions udgøre ~128 KB, hvilket ikke burde være et problem.

Jeg kan ikke forestille mig nogle aktiviteter fra søgebotter, der skulle udløse læsning/skrivning til 'sessions'?

Sessions er vel kun til for at implementer en eller anden form for statefull konversation - eller ?

Det er nok nærmere uafsluttede tråde/Garbage Collectoren der er på spil i dette scenarie.

Eller måske båndbredde begrænsning, da der ikke skal ret mange samtidige brugere til á 873 KB/stk for at fylde en linie.

Men det kommer an på hvilke fejlmeldinger folk fik. Hvis det var en fejl fra serveren, så er det systemet, men hvis det var en browserfejl (aka 'timeout on connection'/'unable to connect' etc), så var det båndbredde.

Hvis man fik den der 'Internal server error', så var det sandsynligvis GC'en, der havde lidt for travlt med at rydde op.

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