Steeds meer mobiele websites en apps bezwijken onder piekbelasting. Zo was de nieuwe Wie is de Mol app nog maar net gelanceerd of het aanmeldproces kon de grote stroom bezoekers niet goed verwerken. Hetzelfde gold bij de Nationale IQ Test. Zeker bij TV-programma’s biedt het zogenaamde ‘second screen’ mooie kansen voor meer interactie met je publiek en de kijker ook buiten de uitzending aan je te binden. Maar als je applicatie op dat ‘second screen’ het op het moment suprême laat afweten, bereik je juist het tegenovergestelde. Hoe bereid je je dan wel goed voor op die hausse gebruikers?
Alle populaire ‘second screen’ applicaties hebben één ding gemeen: ze hebben binnen een hele korte tijd enorm veel gebruikers en activiteit. Een hele andere situatie dan bij (mobiele) websites of applicaties waarvan het gebruik veel normaler is verdeeld. Hier komen bezoekers niet allemaal binnen een kwartier binnen en klikken ze niet allemaal binnen 10 seconden op de betaal,- of stemknop. Iets wat business as usual is bij apps van TV-programma’s.
Legale DDos-aanvallen
Stel er komt tijdens een uitzending een vraag in beeld die iedereen die interactief met de app meespeelt, binnen 15 seconden moet beantwoorden. Je kunt wel bedenken wat dit betekent voor de servers. Er komen binnen 15 seconden ruwweg 100.000 antwoorden binnen die allemaal verwerkt moeten worden. En zonder hoge responstijden en fouten natuurlijk. Je zou dit bijna legale DDoS-aanvallen kunnen noemen.
Het is vrij complex om een serveromgeving zodanig in te richten dat het deze enorme bulk aan belasting goed kan verwerken. Maar het is mogelijk, met een goede voorbereiding en aandacht voor onderstaande punten:
1. Ontwikkelen met een performance mindset
Het kunnen verwerken van dergelijke bulkverzoeken kan bijna alleen maar goed gaan als de applicatie zeer effectief is ontwikkeld. Responstijden van de verzoeken moeten echt zo laag mogelijk blijven, anders is de kans groot dat er op de achtergrond teveel verwerkingscapaciteit nodig is om zoveel verzoeken parallel te kunnen uitvoeren. Hoe lager de responstijd, des te minder verwerkingscapaciteit er dus nodig is, dus hoe meer een systeem aankan en hoe minder parallel er gewerkt hoeft te worden. Het gaat dus om super efficiënte verwerking, dat betekent low level database queries en voorkomen van het gebruiken van ‘zware’ frameworks. Ontwikkelaars dienen zich bij het schrijven van elke regel code bewust te zijn wat de impact zou kunnen zijn als die regel bij wijze van spreken 100.000x per seconde wordt uitgevoerd.
2. Schaalbare applicatie & cloud
Het is belangrijk dat de applicatie schaalbaar wordt ontwikkeld, waarbij de belasting niet wordt beperkt door een enkele database. Als je bijvoorbeeld een app ontwikkelt voor een TV-show waarbij constant nieuwe antwoorden worden toegestuurd is het belangrijk te kiezen voor een decentrale database (of gebruik sharding). De applicatie moet zo zijn ingericht dat je heel eenvoudig nieuwe servers kunt bijschakelen, zonder dat je deze daarna nog handmatig moet configureren. Zodoende wordt het heel makkelijk om bijvoorbeeld cloud-diensten te gebruiken waarbij je precies zoveel virtuele systemen start als dat je tenminste nodig hebt. En dat maakt het per definitie een best practice om voor dit soort type apps of websites, waarbij er in een korte periode een enorme bulk aan belasting is, gebruik te maken van cloud-diensten. Het voordeel daar is dat je heel eenvoudig, met een druk op de knop, virtuele systemen kunt opstarten die binnen een minuut bruikbaar zijn. Grotere cloud-diensten zoals Amazon of Google bieden je ook de mogelijkheid om op basis van belasting automatisch deze systemen te laten op- of afschalen.
3. Performance testen uitvoeren
Als je te maken hebt met websites of apps die in hele korte tijd een enorme hoeveelheid gebruikers of verzoeken te verwerken hebben, dan brengt dat per definitie al een enorm groot performance-risico met zich mee. Mijn ervaring is dat de kans dat zo’n (nieuwe) out-of-the-box applicatie direct een goede performance levert, nihil is. Om voor de inzet van deze applicaties de performance inzichtelijk te maken, is het uitvoeren van performance testen een must. Hiermee kun je de verwachte tijdelijke piekbelasting simuleren en zodoende nagegaan of de omgeving deze belasting wel aankan. Performance testen geven je antwoorden op de volgende kritieke vragen:
- Wat is de maximale capaciteit van de omgeving en kan het de verwachte belasting wel aan?
- Schalen mijn servers mee, snel genoeg en zonder fouten?
- Is mijn applicatie wel optimaal ontwikkeld en zijn de servers optimaal getuned voor dergelijke belasting?
Generale repetitie
In de laatste jaren heb ik veel grote performance testen uitgevoerd voor websites en apps die binnen korte tijd een enorme hoeveelheid gebruikers moeten verwerken. Testen van 100.000 tot een miljoen gelijktijdige gebruikers zijn daarbij geen uitzondering. En nooit, echt nooit, was de performance in één keer zoals gewenst. Als je maximaal wil profiteren van de inzet van het second screen en wil ‘shinen’ op het moment dat het ertoe doet, denk dan aan een goede generale repetitie. Deze kan uiteindelijk het grote verschil maken voor de gebruikservaring en de waardering van van je applicatie.
