Cachingfejl lagde nøgenbilleder på Her & Nu offline

Rettet: En ny serie nøgenbilleder af en danserinde fik for anden gang på to uger ugebladet Her & Nus hjemmeside til at gå i sort. En ny cachingstrategi holdt ikke hele vejen i mål.

Er der noget, danskerne gerne vil i frokostpausen, så er det at se på nøgne damer. Og danserinden Stine Kronborgs evakostume er tilsyneladende voldsomt interessant for tiden.

Det kulørte ugeblad Her & Nu har for anden gang på to uger bragt en serie billeder af en afklædt Stine Kronborg, og for anden gang er offentlighedens trang til bar hud blevet skuffet på grund af tekniske problemer.

Læs også: Her & Nu-hjemmeside lagt ned af bare bryster

»Første gang blev vi en smule overraskede over, at en nøgen pige generede så meget trafik,« siger Tue Korsemann, som er driftschef hos Her & Nus hostingleverandør Solido Hosting til Version2.

Belært af erfaringen havde Solido Hosting og Her & nu da også udarbejdet en ny strategi, så sitet ikke ville blive lagt ned en anden gang på grund af høj trafik.

»Vi havde dialog med dem (Her & Nu, red.) sidst om problematikken. Og de har sat deres webbureau på sagen, så sitet bliver bedre proportioneret til at klare høj trafik,« siger Tue Korsemann til Version2.

Samtidig aftaltes en ny cachingstrategi, så da Her & Nu advarede om, at de igen ville bringe en "interessant" billedserie, satte Tue Korsemann en F5 load balancer foran websitet og lavede en analyse på, hvad på sitet, der gav mening at cache.

»Det satte load-tiden betragteligt ned. Men desværre kom vi til at cache en lille smule for meget - nemlig noget dynamisk genereret indhold, som så gav en fejl, der blev lagt i cachen. Derfor var der nogle, der i en kort periode fik en fejlmeddelelse, når de forsøgte at gå ind på sitet,« siger Tue Korsemann til Version2.

Cachingen af det dynamiske indhold blev herefter slået fra, og siden da har sitet kunne trække alle de besøg, der har været. Tue Korsemann understreger, at Solido Hosting havde fået frie hænder til at gøre, hvad end der skulle til for at holde sitet i luften, og at man i den forbindelse havde advaret Her & Nu om, at det kunne opstå fejl i forsøget på at holde loadet nede - hvilket Her & Nu var fuldt indforstået med, da sitet ikke er optimeret til at blive cachet.

»Herognu.com har haft mere end 50 gange så meget trafik som på en normal dag. Det er også derfor, det kan komme bag på hjemmesiden, hvis den ikke er vant til at håndtere den load. Load-test giver sjældent et helt retvisende billede, og når man når grænsen, så når man den hårdt,« forklarer Tue Korsemann.

Opdateret 10. november 7.23: Adskillige misforståelser rettet i tekst og overskrift. Blandt andet er "fem load balancere" rettet til "en F5 load balancer."

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

Er det kun mig, der ikke kan finde noget i artiklen, der underbygger overskriftens påstand om 'lagde [...] ned'?
Der har været en fejl der har givet forkert indhold, men det er i min bog noget andet.

  • 2
  • 0
Niels Henrik Sodemann

For at siden også kommer til at svare på herognu.com (uden www.)

Når jeg læser om 5 load balancere for at servere noget statisk content er man ret sikker på at nogen gør noget ret forkert. Den tanke forstærkes lidt af at det ikke svarer uden www. foran.


Hej Thomas,

At der ikke svares på http://herognu.com skyldes en forkert konfiguration der "peger" den tilhørende A-record på https://www.herognu.com (port 433) i stedet for http://www.herognu.com.

Som du er inde på er det ikke svært at få statisk indhold til at fungere. Man kan f.eks. benytte et CDN (content delivery network) som f.eks. Akamai eller Amazon AWS S3/CloudFront.

Amazon AWS/CloudFront som vi benytter i Queue-it håndterer f.eks. uden videre 1.000 megabits per sekund og peak request rates på 1.000 requests per second.

Langt de fleste CMS systemer understøtter filer fra andre kilder end sin egen database og herfra kan det da klart anbefales blot at lægge sine mest populære filer eksternt ift. sin infrastruktur, f.eks. på de omtalte CDN'er.

Men der er da en god historie at site går ned pga. de omtalte billeder. Gad vide hvor mange der kendte www.herognu.com tidligere ;-)

Niels Henrik Sodemann, Queue-it (www.queue-it.net)

  • 2
  • 2
Thomas Jensen

Hej,

"At der ikke svares på http://herognu.com skyldes en forkert konfiguration der "peger" den tilhørende A-record på https://www.herognu.com (port 433) i stedet for http://www.herognu.com."

Hvordan peger man i dns på en port ?

Jeg ser ingen grund til at anvende et CDN for at aflevere noget så trivielt som statisk content som man må antage udelukkende er interessant i et meget begrænset område (Danmark).

vh
thomas jensen

  • 4
  • 0
Niels Henrik Sodemann

Hvordan peger man i dns på en port ?


Det mappes ofte i firewall, load-balancer og/eller på web-server.

Ok, pointen omkring CDN var ikke at lave et globalt setup, blot et simpelt forslag til hvordan man nemt undgår at 10 billeder / rigtig mange brugere / over kort tid lægger et informations site ned. Og det fremgår jo af artiklel at det blev lagt ned, at der var rigtig mange bruger og over kort tid (frokostpause).

Niels Henrik Sodemann, Queue-it (www.queue-it.net)

  • 1
  • 1
Bo Thomsen

Den eneste fordel ved et CDN er ikke kun at der normalt er storage i flere lande men jeg tror også at Amazon CWS eller Akamai kan levere højere hastigheder og flere request en ens egen web host.

  • 1
  • 0
Lars Balker

Mon ikke der er et par i branchen der ryster bedrøvet på hovedet over at nogle firmaer synes det er god PR at lufte sit beskidte tøj i medierne.

Det er jo altså ikke rocket-science længere at skalere et CMS til at smide data efter så lille et sprogområde som Norden, også uden fem(!) load-balancere.

(Jeg skal hilse og sige at vg.no eller msn.dk normalt giver lidt flere hits end dem I var så duperede over at få fra eb.dk sidst.)

  • 5
  • 0
Niels Henrik Sodemann

Nu blev der specifikt sagt at det var en A-record :))


"peger" i citationstegn samt "tilhørende" forstået som "redirect" til https://www.herognu.com der jo er en HTTPS adresse.

Hvis man f.eks. skriver http://version2.dk bliver man korrekt redirected til www.version2.dk. Det sker sandsynligvis på firewall, load-balancer og/eller webserver.

Niels Henrik Sodemann, Queue-it (www.queue-it.net)

  • 1
  • 0
Jeppe Toustrup

Jeg tror og håber de gør det så simpelt som muligt i webserveren. Alt andet lugter af mersalg.

$ curl --head http://version2.dk/  
HTTP/1.1 301 Moved Permanently  
Server: nginx/1.0.9  
Date: Thu, 10 Nov 2011 09:05:02 GMT  
Content-Type: text/html  
Content-Length: 184  
Connection: keep-alive  
Location: http://www.version2.dk/

Det ligner det er en reverse proxy som står foran webserveren, da requests til www.version2.dk bliver svaret af en Apache server.

  • 0
  • 0
Jonas Høgh

"peger" i citationstegn samt "tilhørende" forstået som "redirect" til https://www.herognu.com der jo er en HTTPS adresse.

Det var en temmelig søgt søforklaring. En HTTP-forespørgsel til 109.238.50.1 på port 80 med host-header "herognu.com" returnerer en HTTP 301 moved permanently, der peger på https://www.herognu.com

Samme server, hvorpå www.herognu.com også peger, svarer ikke på port 443, så det fejler. Redirect mekanismen har intet med DNS at gøre.

  • 1
  • 0
Niels Henrik Sodemann

Det var en temmelig søgt søforklaring. En HTTP-forespørgsel til 109.238.50.1 på port 80 med host-header "herognu.com" returnerer en HTTP 301 moved permanently, der peger på https://www.herognu.com

Samme server, hvorpå www.herognu.com også peger, svarer ikke på port 443, så det fejler. Redirect mekanismen har intet med DNS at gøre.


Helt enig i at det ikke er en DNS mekanisme, men der har jeg nu heller ikke skrevet. Som du jo helt sikkert er med på, benyttes HTTP 301 som permanent "redirect".

Så vi er jo bare enige om at det sted hvor der er opsat at herognu.com skal svarer HTTP 301 (permanent redirect) til https://www.herognu.com, virker hvis det ændres til http://www.herognu.com i stedet.

Herved kan vi så lukke spørgsmål fra post 2 omkring om hvorvidt der var sammenhæng mellem load-balancere og det forhold at http://herognu.com ikke svarer.

Niels Henrik Sodemann

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