Case Studie - extreem upscalen van Shaklee

Shaklee is terecht gekomen op een landelijke (US landelijk dus) talkshow waarbij de site werd getoond. Vantevoren was ze verteld dat hun website zou crashen, want dat gebeurde bij elke website die daar getoond werd. Met 20MIO (20.000.000) kijkers is daar een aardige groep mensen die mogelijk zouden surfen naar hun site. Vóór deze show hebben ze hun infrastructuur onder de loep genomen en ontdekten dat ze 5 jaar niets eraan hadden gedaan,
omdat ze maar zo'n 10% per jaar groeien.

Welke uitdagingen hebben ze zichzelf opgelegt? Het beperken van zo'n beetje alles per transactie. Hieronder hun strategie in een notedop:

Beperken van Server Requests per Transaction
Je kunt de request naar je eigen server beperken door statische content naar andere sites te verplaatsen. Dus plaatjes, flash, video's werden naar gedistribueerde netwerken geporteerd (CDN, Akamai, Limelight).

Beperken van server CPU en geheugen gebruik per transactie
SSL encryptie werd door gespecialiseerde hardware op zich genomen. Alle pagina's werden weer statisch gemaakt, met maar een paar uitzonderingen (standaard is dat tegenwoordig meeste pagina's dynamisch zijn). En het gebruik van Layer 4 load balancing. Ook hebben ze zoveel mogelijk module's uit Apache gestript en er werd níet geclusterd (voor een eenvoudige
webshop was clustering geen voordeel). Session management was uitgezet, omdat de enige belangwekkende informatie zou zijn: product en prijs.

Beperken van netwerkbelasting per transactie
Om te beginnen werd alle HTML geoptimaliseerd dus Dreamweaver eruit en HTML met de hand doen. De plaatjes die gebruikt werden waren zeer strikt qua formaat en geoptimaliseerd voor het web. Verder werd er alleen HTTP1.1 gebruikt en werd de NAS er uit gegooid.

Beperken van zwakke punten in het netwerken
Ze hebben meerdere ISP's genomen waardoor ze meerdere lijnen binnenkregen in hun datacenter en ze hebben een aantal 'slapende' systemen ingezet (routers, switches, firewalls, ethernet cards in de servers).

Beperken van zwakke punten in applicaties
Hun applicaties zijn zo gebouwd dat ze minimaal gebruik maakten van webservices en (verbazingwekkend) hebben ze de database er uit gegooid om deze schakel te elimineren. Verder hebben ze ook de realtime verbindingen met bijvoorbeeld de Creditcard companies en met hun magazijn uitgeschakeld. Ook werd zoveel mogelijk rekenkracht aan de client kant gebruikt (creditcard check met javascript, naam- en adrescheck met javascript (waardoor je ongeveer 0,5% van je klanten misloopt) en een cookie-based shopping cart om het gemis van een dB op te vangen).

Andere dingen
De analysefunctie van de website was uitgezet, met name omdat de pakketleverancier niet kon garanderen dat onder de druk hij niet zou bezwijken. Verder hebben ze het zo gemaakt dat checkout op slechts één pagina komt. En, als extra backup: een pagina met 'sorry' en het telefoonnummer van de tele-winkel. Orders werden gebatched en pas verwerkt zodra het verkeer het toeliet (zodat je bevestigingsmail pas later verwerkt, CreditCard/adres en orders later controleert, etc).

Feathterweight Design Pattern
Ze hebben gebruik gemaakt van het Featherweight DP waarover ik echter op het 'net weinig heb kunnen vinden. Een paar kernpunten eruit zijn: geen externe service calls, zoals adress verificatie. Elke webserver was standalone en zónder cluster management. Stateless server sessions.

Het eindresultaat?
HTML traffic op 60MBit/seconde, grafisch 200MBit/seconde, 8500 requests/seconde op de servers. En dit alles gebouwd in 20 dagen (én getest) met Zend.