Fra server-crash til et ubegrænset antal besøgende
Et online community gik i løbet af et halvt år fra at have 2 millioner til 20 millioner besøgende om måneden. Frontend-udvikler Simon Dragsbæk Petersen fortæller om, hvordan han og teamet under tidspres fik bygget et nyt site, der kunne håndtere alle besøgende – uden server crashes.
“Vi er for sent ude.” Dén tanke gik gennem hovedet på Simon Dragsbæk Petersen, da han satte sig i stolen som lead frontend-udvikler på et verdensomspændende online community.
På det tidspunkt var antallet af unikke besøgende på hjemmesiden allerede eksploderet. Sitet var gået fra at have 2 millioner til 20 millioner unikke besøgende om måneden på et halvt år. Og på såkaldte peak fridays, hvor trafikken fra hele verden var allerstørst, var op mod 25 millioner besøgende forbi siden.
“Dér begyndte det at halte. WordPress-bloggen kunne lige presses til 20 millioner, men da vi ramte de 25, havde vi server-crashes. Og når man først er nået dertil, skal det gå rigtig stærkt med at få bygget noget nyt,” siger Simon Dragsbæk Petersen.
Mærkelig stack
Opgaven var at få støbt et fundament, en platform, som fremover kunne skalere til flere 100 millioner aktive brugere om måneden. Og dét krævede af flere grunde et helt nyt system.
For det første fordi den oprindelige stack var “en mærkelig sammensætning”, som Simon Dragsbæk Petersen udtrykker det. Den bestod af en WordPress-blog og en webshop bygget i Magento – begge i php; det mest anvendte programmeringssprog til dynamiske webløsninger. Derudover havde sitet en webapplikation, der var bygget i Yii – også et php-framework.
“Hvert framework kommer med nogle foruddefinerede funktioner, som udviklerne er bundet til. Det betyder, at tingene ikke er genkendelige på tværs af sitet. Det afspejler enten dårlig ledelse, uvidenhed eller start up-ånd, hvor man bare skal ud over rampen uden at have tænkt igennem, hvad målet med systemet er,” siger Simon Dragsbæk Petersen.
Derudover var det oprindelige site understøttet af Varnish Cache software, som er designet til indholdstunge, dynamiske hjemmesider, og har til formål at aflaste backend-serveren for at undgå overload. Og det var da også den, der fik tandhjulene til at dreje, da sitet fik rigtig mange besøgende.
“Men selvom vi cachede de fleste resultater, fik vi nogle gange så mange hits, at vi ikke kunne håndtere dem. Der var simpelthen brug for en helt ny arkitektur.“
Facebook trak brugerne
Det online community havde ramt en åre; efterspørgslen var der. Derudover var årsagen til den pludselige og massive interesse for communitiet også, at websitet trak ekstremt mange besøgende ind på bloggen via Facebook – i modsætning til mange andre virksomheder, der typisk henter kunder via SEO-optimering på Google.
“Virksomheden havde fundet en vej i Facebooks algoritmer til at booste indhold, som gjorde, at sitet fik højere click-rates end nogensinde før,” fortæller Simon Dragsbæk Petersen.
Solid tankegang
Sammen med udviklingsteamet kom Simon Dragsbæk Petersen frem til, at det vigtigste var at kunne levere hurtigt og stabilt indhold på sitet, som brugerne kunne læse. Derfor besluttede de at generere alle blogposts som flade, statiske filer; HTML, CSS, JavaScript. Filerne blev lagt ud på en Simple Storage Service og blev distribueret i hele verden via et Content Delivery Network (CDN).
“Det gode ved statiske filer på netop vores case var, at vi havde rigtig mange besøgende, der læste de samme artikler. Derfor undgik vi load på serveren, når content blev serveret som HTML-filer. Filerne var lavet én gang for alle, og så betalte vi bare for den data, der kørte frem og tilbage. Det er en ret solid måde at tænke på,” siger Simon Dragsbæk Petersen med et smil:
“Med den metode det er bygget på nu, kan websitet potentielt klare et ubegrænset antal besøgende.”
Den eneste ulempe er, når der bliver lavet større designændringer i templates. Så skal alle posts genereres igen. Det tager omkring 30 sekunder at rette 10.000 posts. Skribenterne oplever også, at der går 10-15 sekunder før deres post lægger sig i kolonnen for ‘recent fives’.
“Det betyder, at der er et lille tidsrum med inkonsistens på sitet, men jeg mener, at det er et drawback, som er til at leve med,” siger Simon Dragsbæk Petersen.
Systematik
Simon Dragsbæk Petersen valgte helt at kassere det gamle site sideløbende med, at det nye blev skabt. Først byggede teamet et nyt CMS i Angular, et modulbaseret framework, som i byggefasen blev integreret med WordPress’ publishing af posts. Derefter byggede udviklerne en helt ny frontend i React. I alt tog det otte måneder, inden det nye site lå klar.
“Vi var i byggefasen nødt til at skrue ned for publiceringen af de mest populære posts for ikke at få for meget trafik. Og det er ufedt, når man som virksomhed peaker som aldrig før.”
Undervejs i arbejdet satte Simon Dragsbæk Petersen en dyd i at have to sæt øjne på alt, der blev bygget:
“Code reviews gør, at en hel del typos bliver fanget og rettet. Det gør arbejdet meget lettere for dem, der skal bygge videre på sitet,” fortæller han.
Grundlæggende er Simon Dragsbæk Petersen stærkt optaget af struktur og systematik helt fra start. For timerne forud for byggefasen er aldrig givet dårligt ud:
“Jeg stiller mig ved en tavle sammen med teamet, og så tegner vi; Arkitekturen, ønskescenariet, og alt hvad der kan risikere at gå galt. Den fremgangsmåde er jeg stor fortaler for.”
Blå bog:
Navn: Simon Dragsbæk Petersen
Alder: 26 år
Arbejde: Har netop færdiggjort et projekt hos Bolighed A/S gennem ProData Consult. Derudover er SimonChief Technology Officer (CTO) og co-founder af introDus.
Uddannelse: Mediegrafiker fra KTS
