Steeds meer mobiele websites en apps bezwijken onder piekbelasting. In mijn ogen is een goede remedie het toepassen van een 'second screen'. Goede voorbereiding is echter wel raadzaam.
De nieuwe Wie is de Mol-app was nog maar net gelanceerd of het aanmeldproces kon de grote stroom bezoekers niet goed verwerken. Hetzelfde gold bij de Nationale IQ Test. Zeker bij yv-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 tien 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 vijftien seconden moet beantwoorden. Je kunt wel bedenken wat dit betekent voor de servers. Er komen binnen vijftien seconden ruwweg honderdduizend 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 honderdduizend keer 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 shard). 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 honderdduizend 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 je applicatie.
Leuk artikel Joerek en dit is zo’n geval waarin cloud diensten het meest hun waarde kunnen bewijzen. Een spelshow duurt een uurtje en voor de rest heb je hem niet of nauwelijks nodig. Met AWS of GCP kost het verwerken van een paar miljoen requests slechts een paar euro, terwijl dit enorm duur is als je het zelf zou willen regelen vanuit je eigen serverruimte.
En zoals je zegt, voor het eerste testen op schaal levert altijd issues op. Nog leuker vind ik dan de quote van Mark Twain:
“A man who carries a cat by the tail learns something he can learn in no other way.”
@ Joerek
Goeie vraag, maar zou het niet zeer eenvoudig aan Java kunnen liggen?
Voor mij is dat “appeltje – eitje” derhalve voor elke ‘snotneus’ ook.
Java kan je niet beveiligen, wel (zelf) veiliger maken – server-side…
Helaas worden nagenoeg alle app’s geschreven in Java en daar begint het ‘gedonder. Goed stuk-i overigens!
Leuk artikel, wat ik mij afvraag is hoe de synchronisatie van de gebeurtenissen tussen app activiteit en tv-uitzending op te lossen is.
Ik heb een keer geprobeerd met de nat.iq test met de app mee te spelen, maar wat bleek,
De tv-uitzending liep achter op de timer in de app.
Wanneer je in de app dus 1 minuut bedenktijd hebt, en de vraag op tv pas op de inmiddels verlopen 45 seconden wordt gesteld wordt het voor de gebruiker wel lastig op tijd te antwoorden.
In zo’n geval verbaasde het me dat de vraag niet op hetzelfde device/workflow voorkwam als waar je moet antwoorden.
Of dat de tv-uitzending niet via dezelfde app werd gestreamd met de tv als lokale second screen.
Met de uitzendingen van het laatste wk kon je in de wijk goed horen aan het gejuich wie er met de grootste vertragingen zat, zeg maar een soort virtual wave.
In deze tijd van virtualisatie en tv diensten waar buffering optreedt ben ik benieuwd hoe je daarmee met je second screen rekening kan houden.