Weer even bellen met: buienradar.nl
Zes maanden na mijn interview met Edwin Rijkaart van Buienradar.nl ziet de wereld er heel anders uit voor buienradar. Tijd voor een update. Het is ontzettend hard gegaan. Eigenlijk geeft Edwin aan dat het bijna te goed gaat, ze kunnen het bijna niet bij houden. Edwin meldt mij ‘Ik ben volop bezig echter loop tegen een “groot” probleem aan. Buienradar zat in mei op dik 5 miljoen uniek. Met de eerste week van juni erbij over de afgelopen 30 dagen zelfs op dik 7 miljoen uniek. En dan was mei nog een droge maand. Op droge dagen (zoals afgelopen maandag 9 juni) komen er nog rustig 500.000 unieke bezoekers kijken.’
De site groeit nog steeds erg hard. In de lijsten van STIR en Multiscope zie je de groei ook duidelijk terug. De site staat steevast in de top 5 van Nederland en is hard op weg naar een permanente top 3 positie.
Edwin licht toe ‘Dat zijn cijfers van mensen die ook daadwerkelijk op buienradar.nl komen. Dus geen gadgets, componenten e.d. Je ziet het ook terug in de stir cijfers van april. Mobiel meten we nog niet. Wel pageviews. Die zijn nu iets meer dan 1 miljoen.’
Ik vraag mij af of dit ook effect heeft op de andere sites van BOOM bv zoals fileindex.nl en meteox.com. Edwin licht toe: ‘Fileindex heeft een enorme stijgende lijn (ook volgende maand in de stir te vinden) en daar komt als het goed is een nieuwe file feed op na de zomer vakantie. Het gaat dus allemaal erg hard. Ook internationaal. Meteox zit in de stir met een marktaandeel van 9,8% in april (alleen NL bezoekers). Alleen Meteox alleen al is groter dan alle andere weersite in Nederland. Wij zitten daar nu op 1,8 miljoen uniek per maand.’
En wat zijn de plannen verder? Ik hoorde dat je met twee internetconcepten in vergevorderd stadium bent, die net zo simpel zijn als het buienradar-concept? Edwin: ‘Dat klopt, maar inhoudelijk kan ik daar helaas nog steeds niets over zeggen. Ik hou je op de hoogte. Wel ben ik er achtergekomen dat door alle hectiek rondom de groei van buienradar er bijna geen tijd meer om te ondernemen. Ik loop met allerlei ideetjes rond alleen doordat er geen tijd is worden deze niet opgestart. Daar wil ik verandering in brengen. Ben nu alleen maar bezig met het beheren van de website(s). Inmiddels hebben we een 3e datacentrum erbij. In totaal nu 3×1 gigabit aan bandbreedte. Als ik vooraf wist dat het allemaal zo snel zou gaan had ik het anders aangepakt 🙂 Maar dat is natuurlijk wel de gein van ondernemen. Zeven van de 10 projecten floppen. De rest is succesvol. Het is ook een “luxe” probleem maar wel iets dat we in 2008 willen aanpakken.’
Hoe kan het nu te goed gaan met een site? Kwestie van servers erbij zetten en knallen lijkt me. Uitspraak lijkt me meer een schreeuw om aandacht. Jammer, vind namelijk buienradar.nl een geweldig concept en heeft deze aandacht helemaal niet nodig. Had liever een goede analyse gezien van hoe buienradar.nl de toename van traffic nu aanpakt. Schaalbaarheid is namelijk één van de grootste uitdagingen van populaire sites; zeker social networksites waar de gebruikers onderling ook nog eens interactie met elkaar hebben.
@Marco: die schreeuw om aandacht is van mij en niet van buienradar. Ik zocht een teasend begin. En hoe ze de toename van traffic aanpakken staat er in: ze zijn opgeschaald naar 3×1 gigabit aan bandbreedte.
@Mark: had de titel al aangepast! Vwb die schaalbaarheid, ik zou daar graag eens wat meer over willen lezen. Wij lopen zelf ook regelmatig tegen performanceproblemen aan (zeker als we weer eens een linkje krijgen van NU.nl of Geenstijl). Op boomr.nl, een social network voor startende muziekbands, hebben we ook flinke performance problemen gehad. Ben zelf onvoldoende technisch om de do’s en don’ts hiervan te begrijpen maar zou graag zien dat iemand dit onderwerp eens oppakt!
@Mark
Nomen est omen. Opschalen voor dummys gaat over het vergroten van een swish-bestand 🙂
Wellicht verstandig om te beginnen in de Wikipedia bij termen zoals scalability, load balancing enz.
Wat betreft schaling mag buienradar zich rekenen tot de gelukigsten van het internet, de static content die een keer per paar minuten geupdate wordt is zonder veel moeite (lees: database-hacks) op te schalen. Eigenlijk gewoon een probleem voor het bedrijf dat de hosting doet. Dit stelt allemaal niets voor, zoals ook Marco zegt, vergeleken met dynamische social networking sites of andere sites die continu geupdate worden dmv grote hoeveelheden user generated content.
Voor de goede orde: wij hebben geen performanceproblemen. Ja, tuurlijk, er is altijd wel iets maar met 3×1 gigabit en genoeg servers kunnen we het piek verkeer gemakkelijk aan. We missen af en toe alleen wat “handjes”. Een 7 daagse werkweek is niet altijd prettig. Goede techneuten zijn vaak moeilijk te vinden. Maar om te verkomen dat het een zielig verhaal wordt: ik doe het nog steeds met plezier alleen hebben we wat meer “handjes” nodig. That’s all.
Het optimaliseren van een server is op zich niet zo moeilijk alleen moet je wel weten op welke knoppen je moet drukken en waar de limieten liggen. Wij hebben die kennis gelukkig zelf in huis. Het zal wel arrogant klinken maar ik hoor regelmatig grootspraak van bekende firma’s die totaal niets weten van server optimalisatie. Een grote mond dat ze het wel even oplossen maar in de praktijk is het toch vaak even anders.
@Edwin: heb inderdaad ook nog nooit performanceproblemen ervaren op buienradar.nl; altijd beschikbaar en snel, complimenten dus! Ik reageerde hier op de stelling dat het te goed zou gaan met buienradar.
Maar even los van die discussie is de vraag hoe je snel populair wordende site het beste kunt opschalen. Zou daar graag wat meer inzicht in willen!
@Marco
Wij hebben vanaf het begin gebruik gemaakt van de overcapaciteit op Beurs.nl Geen structurele oplossing maar het was wel even handig. Nu is het niet meer maar zeker ook niet minder dan servers bij prikken en weten hoe je ze moet inrichten.
Het is niet 1,2,3 uit te leggen hoe je moet opschalen. Dat is geheel afhankelijk van wat je site precies moet doen. Loopt je database te traag? Wellicht wat meer CPU kracht. Maar vaak kun je met wat eenvoudige trucjes je server ook beter laten draaien.
Gewoon een simpel praktijk voorbeeld die voor een ieder waarschijnlijk weer anders is:
Neem een platform als FreeBSD. Standaard staat de server limit op (ik dacht) 150. Die kun je rustig op 750 zetten. Dan kan de machine al heel wat meer requests afhandelen. Maar daarin moet je een balans zoeken want grote kans dat je database dan weer traag gaat worden omdat die op zijn beurt weer meer verzoeken krijgt.
En zo puzzel je naar de beste oplossing. Maar nogmaals, dat is niet zo 1,2,3 uit te leggen en is voor iedere site anders.
@Joost
Zonder mij verdiept te hebben in EC2 en S3: staan die bakken in de VS? Daar heb ik hele slechte ervaringen mee. Soms knijpen ze wel eens poorten en dan kun je veel capaciteit hebben in de VS maar dan is het totaal onbereikbaar. Als deze servers ergens in “de buurt” draaien kan dat zeker een oplossing zijn.
@Edwin: Amazon heeft geloof ik een aparte Europa-locatie (iig voor S3). Is op hun tarieven-pagina’s te selecteren meen ik.
@Edwin, EC2 (de rekenkracht) staan in de U.S., voor opslag kun je zowel voor U.S. als Europa kiezen. Desondanks zijn mijn angsten voor dit soort oplossingen niet zo groot als de jouwe.
Excuses Edwin, Marco en Mark, hierbij graag wat ‘ongegeneerd’ spammen. Samen met Amazon bieden wij een autoscaling dienst (jitscale) op basis van EC2 (en evt. S3, helemaal afhankelijk van het platform). Al denk ik dat er al snel een hoop te winnen valt met slim cachen en het ’trechteren’ van TCP verbindingen. Hierdoor neemt de connectie load snel af en de performance dus sterk toe. We kennen dit soort problemen (nu.nl bijv) en kijken graag een keer, natuurlijk geheel vrijblijvend, met je mee.
Het leuke aan zo’n EC2 constructie is dat je betaalt voor wat je daadwerkelijk gebruikt ipv een grote investering voor een platform. De vertragingen doordat het EC2 serverpark (nog alleen) in de VS staat is niet verschrikkelijk, reken op zo’n 80ms in vergelijking met 3 – 10 ms hier in NL. Als het platform sneller performt is die winst veel sterker zichtbaar dan het verlies aan netwerk latency.
@Jos, dit gaat puur over de netwerk vertraging, niet de bandbreedte. Per hit moet je 80ms wachten op het resultaat. Aangezien hits parallel door een browser worden uitgevoerd ben je in principe deze vertraging maar 1 of anderhalf keer kwijt. Voordeel is dat met een EC2 platform je processing snelheid veel hoger kan zijn (je hebt immers ‘unlimited’ resources, afhankelijk van de applicatie kun je dus veel sneller een response genereren). In die processing snelheid zit normaal je vertraging (die kan halve seconden of meer zijn). Voor de duidelijkheid gebruik ik altijd de auto-snelweg analogie: In principe praat je over de snelheid van de auto’s, de breedte van de weg en het moment waarop de auto’s vertrekken. De snelheid van de auto’s is 8x trager (maar in milliseconden!), maar ze vertrekken veel sneller (vaak in seconden) en de weg is net zo breed dus je kan met veel auto’s tegelijk rijden.
BION I’m imsdepser! Cool post!
Er staat voor vandaag dat het niet zou gaan regenen maat het regent zelfs keihard
Er staat voor vandaag dat het niet zou gaan regenen maat het regent zelfs keihard
Gerelateerde artikelen
Marketingfacts. Elke dag vers. Mis niks!
Marketingfacts. Elke dag vers. Mis niks!