![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
Tweakers.net's overcapaciteit
We schaffen geregeld nieuwe hardware aan en de capaciteit daarvan is vaak veel groter dan we nodig hebben. Een goed voorbeeld was onze databaseserver eind vorig jaar.
Dat levert uiteraard wel eens de vraag op waarom we daar dan zoveel geld aan uitgeven, want het kan tenslotte ook goedkoper. "Dat kan toch ook wel met wat minder?" Tuurlijk kan dat. En dat zou ook eigenlijk altijd wel goed moeten gaan.
Nouja, bijna altijd. De backend voor de iPhone-app bevat een component dat weliswaar goed werkte, maar een relatief zware query bevatte. Doordat er vrij veel mensen tegelijk de app uitprobeerden werd die query in twee uur tijd vaker uitgevoerd dan normaal op een hele dag. En dat was daardoor duidelijk zichtbaar op de belasting van de databaseserver, de belasting was een stuk hoger dan normaal.
Hoewel de hogere cpu-belasting volgens mij niet volledig door de iPhone-app werd veroorzaakt is, en er sowieso altijd een paar pittige pieken in de belasting zitten, is er toch wel een zichtbare overeenkomst tussen het moment dat crisp aangaf het gefixed te hebben (20:42u) en de afname van de cpu-belasting op dat plaatje...
Dus om nogmaals die vraag te beantwoorden; Ja, meestal kan een lichtere machine het prima aan... Maar het is prettig om overcapaciteit te hebben als een bepaalde query of stuk code in de praktijk slechter uit blijkt te pakken dan voorzien en/of de betreffende functionaliteit (ineens) zwaarder belast wordt dan voorzien. Zoals nu dus door de iPhone-app.
Het is overigens ook niet ongebruikelijk (een paar keer per maand!) dat een of andere losgeslagen crawler vele (zware) pagina's in rap tempo achter elkaar opvraagt... Onze firewall pikt die vaak wel op, maar als ik de pieken zie die dat oplevert ben ik toch elke keer ook weer blij met de overcapaciteit die we hebben, anders zouden de reguliere bezoekers er wellicht veel meer van merken dan tot nu toe het geval is.
En bij deze heb ik ook een keer een mooi concreet voorbeeld van onze keuze om overcapaciteit aan te brengen en te houden in ons serverpark
Dat levert uiteraard wel eens de vraag op waarom we daar dan zoveel geld aan uitgeven, want het kan tenslotte ook goedkoper. "Dat kan toch ook wel met wat minder?" Tuurlijk kan dat. En dat zou ook eigenlijk altijd wel goed moeten gaan.
Nouja, bijna altijd. De backend voor de iPhone-app bevat een component dat weliswaar goed werkte, maar een relatief zware query bevatte. Doordat er vrij veel mensen tegelijk de app uitprobeerden werd die query in twee uur tijd vaker uitgevoerd dan normaal op een hele dag. En dat was daardoor duidelijk zichtbaar op de belasting van de databaseserver, de belasting was een stuk hoger dan normaal.
Hoewel de hogere cpu-belasting volgens mij niet volledig door de iPhone-app werd veroorzaakt is, en er sowieso altijd een paar pittige pieken in de belasting zitten, is er toch wel een zichtbare overeenkomst tussen het moment dat crisp aangaf het gefixed te hebben (20:42u) en de afname van de cpu-belasting op dat plaatje...
Dus om nogmaals die vraag te beantwoorden; Ja, meestal kan een lichtere machine het prima aan... Maar het is prettig om overcapaciteit te hebben als een bepaalde query of stuk code in de praktijk slechter uit blijkt te pakken dan voorzien en/of de betreffende functionaliteit (ineens) zwaarder belast wordt dan voorzien. Zoals nu dus door de iPhone-app.
Het is overigens ook niet ongebruikelijk (een paar keer per maand!) dat een of andere losgeslagen crawler vele (zware) pagina's in rap tempo achter elkaar opvraagt... Onze firewall pikt die vaak wel op, maar als ik de pieken zie die dat oplevert ben ik toch elke keer ook weer blij met de overcapaciteit die we hebben, anders zouden de reguliere bezoekers er wellicht veel meer van merken dan tot nu toe het geval is.
En bij deze heb ik ook een keer een mooi concreet voorbeeld van onze keuze om overcapaciteit aan te brengen en te houden in ons serverpark
06-'10 T.net Browserstatsistieken 2009-2010 
06-'10 Internetters zijn een stelletje neuroten en kunnen efficienter browsen
Reacties
Door
momania,
dinsdag 08 juni 2010 22:26
Piek belasting is een veel onderschat (of zelfs genegeerd) probleem 
Goed bezig dus
Goed bezig dus
[Reactie gewijzigd op dinsdag 08 juni 2010 22:27]
Door
YopY,
dinsdag 08 juni 2010 22:30
Bleh, wij moeten ook nodig overcapaciteit op onze servers hebben - met enige regelmaat komt er weer een Google Search Appliance die iets te gretig afgesteld is die het hele ding onderuithaalt. En ook als je de cache een schop geeft (dat blijkbaar regelmatig moet gebeuren) heeft hij er moeite mee, maar da's logisch. We zijn in onderhandeling met een paar partijen, hopelijk dat dat verbetering oplevert.
Door
Bubbles,
dinsdag 08 juni 2010 22:34
Overcapaciteit is goed. Helaas is dit bij de meeste bedrijven moeilijk duidelijk te krijgen bij de managers. Maar als hardware loopt te bokken, of software loopt te klapperen, ben je maar wát blij als je zo'n klap kan opvangen, want je gaat ontzettend nat als je bij normaal gebruik al tegen de grenzen aanzit.
Je kan dit bijvoorbeeld ook doortrekken naar het ontwikkelen van software. Pair-programming klinkt op het eerste gezicht ontzettend inefficiënt, maar uiteindelijk valt dat allemaal best wel mee (fouten zie je veel sneller, je kan met z'n tweëen sneller creative oplossingen verzinnen), en als dan 1 van je programmeurs ziek wordt, kan de ander het direct afvangen en doorwerken. Ik heb het wel eens meegemaakt dat er 1 programmeur op een project zat, en die werd ziek een week voordat de boel moest worden opgeleverd. Niemand kon het nog binnen die tijd overnemen en afronden, omdat niemand wist hoe die code in elkaar zat en het best complex was.
Je kan dit bijvoorbeeld ook doortrekken naar het ontwikkelen van software. Pair-programming klinkt op het eerste gezicht ontzettend inefficiënt, maar uiteindelijk valt dat allemaal best wel mee (fouten zie je veel sneller, je kan met z'n tweëen sneller creative oplossingen verzinnen), en als dan 1 van je programmeurs ziek wordt, kan de ander het direct afvangen en doorwerken. Ik heb het wel eens meegemaakt dat er 1 programmeur op een project zat, en die werd ziek een week voordat de boel moest worden opgeleverd. Niemand kon het nog binnen die tijd overnemen en afronden, omdat niemand wist hoe die code in elkaar zat en het best complex was.
Door
googletje,
dinsdag 08 juni 2010 22:46
Over echte overcapaciteit gesproken: Kieswijzer loopt op dit moment toch wel erg slecht.
Door
CodeCaster,
dinsdag 08 juni 2010 22:57
Kan tweakers.net de site niet even mirrorengoogletje schreef op dinsdag 08 juni 2010 @ 22:46:
Over echte overcapaciteit gesproken: Kieswijzer loopt op dit moment toch wel erg slecht.
Door
Calamor,
dinsdag 08 juni 2010 23:02
Mooi om te zien dit. Door dit zou ik wel eens willen weten hoe google er mee omgaat.
Door
EvilWhiteDragon,
dinsdag 08 juni 2010 23:16
Probleem is ook dat capaciteit hebben voor pieken relatief duur is, business wise gezien. Veel kosten voor weinig gebruik enzo he.momania schreef op dinsdag 08 juni 2010 @ 22:26:
Piek belasting is een veel onderschat (of zelfs genegeerd) probleem
Goed bezig dus
Door
Tsurany,
dinsdag 08 juni 2010 23:20
Ik zie pieken maar ik zie nergens de CPU boven de 16,7% uitkomen, heb je zelfs met een zware query nog een gigantische overcapaciteit.
Door
Kees,
dinsdag 08 juni 2010 23:27
Het probleem; zodra de cpu nog veel hoger gaat komen, merk je het in je browser; queries duren iets langer etc.
Ja, we zouden wel 99% cpu kunnen trekken, maar dat merkt de gebruiker ontzettend goed; dus proberen we er (ver) onder te zitten.
Zelfs bij een desktop merk je het verschil al erg goed als hij op 10% cpu vs 90% cpu zit.
Ja, we zouden wel 99% cpu kunnen trekken, maar dat merkt de gebruiker ontzettend goed; dus proberen we er (ver) onder te zitten.
Zelfs bij een desktop merk je het verschil al erg goed als hij op 10% cpu vs 90% cpu zit.
Door
momania,
dinsdag 08 juni 2010 23:28
Het is vaak lastig te bewijzen dat het nodig of goed is. Daarom is wat t.net doet ook zo goed: statistieken bijhouden.EvilWhiteDragon schreef op dinsdag 08 juni 2010 @ 23:16:
[...]
Probleem is ook dat capaciteit hebben voor pieken relatief duur is, business wise gezien. Veel kosten voor weinig gebruik enzo he.
Er zijn volgens mij nog zat bedrijven die niet naar statistieken kijken, of ze niet eens bijhouden. Dat zijn dan ook vaak diegene die de overcapaciteit als overtollige kosten beschouwen. Tenminste, dat denk ik
Uiteindelijk is precies gepaste capaciteit vaak duurkoop ipv goedkoop. Nood onderhoud en/of aanpassingen zijn vaak duurder.
Door
EvilWhiteDragon,
dinsdag 08 juni 2010 23:36
Nja, het lijkt me logisch dat je een marge moet houden, maar bij T.net zie ik een marge van 84%momania schreef op dinsdag 08 juni 2010 @ 23:28:
[...]
Het is vaak lastig te bewijzen dat het nodig of goed is. Daarom is wat t.net doet ook zo goed: statistieken bijhouden.
Er zijn volgens mij nog zat bedrijven die niet naar statistieken kijken, of ze niet eens bijhouden. Dat zijn dan ook vaak diegene die de overcapaciteit als overtollige kosten beschouwen. Tenminste, dat denk ik
Uiteindelijk is precies gepaste capaciteit vaak duurkoop ipv goedkoop. Nood onderhoud en/of aanpassingen zijn vaak duurder.
Dat is in veel bedrijven vermoed ik niet te verantwoorden (helaas).
Door
mvdam,
woensdag 09 juni 2010 01:19
Daarvoor zijn we dan ook tweakerts toch? ^^EvilWhiteDragon schreef op dinsdag 08 juni 2010 @ 23:36:
[...]
Nja, het lijkt me logisch dat je een marge moet houden, maar bij T.net zie ik een marge van 84%
Door
ACM,
woensdag 09 juni 2010 07:45
Dit zijn gemiddelden over periodes van 10 minuten... De kans is dus groot dat het op sommige momenten binnen die 10 minuten veel hoger lagEvilWhiteDragon schreef op dinsdag 08 juni 2010 @ 23:36:
Nja, het lijkt me logisch dat je een marge moet houden, maar bij T.net zie ik een marge van 84%
En dan nog, het systeem is nog maar in zijn eerste gebruiksjaar, we verwachten nog wel wat groei in zijn belasting en over twee jaar moet ie nog steeds dit soort onverwachte pieken op kunnen vangen
[Reactie gewijzigd op woensdag 09 juni 2010 07:51]
Door
RSpliet,
woensdag 09 juni 2010 08:16
Is dit CPU tijd in procenten? Of is dit 'load' zoals Linux dit berekent? In het laatste geval is 16,70 wel bizar hoogTsurany schreef op dinsdag 08 juni 2010 @ 23:20:
Ik zie pieken maar ik zie nergens de CPU boven de 16,7% uitkomen, heb je zelfs met een zware query nog een gigantische overcapaciteit.
[Reactie gewijzigd op woensdag 09 juni 2010 08:17]
Door
ACM,
woensdag 09 juni 2010 08:52
Dit is cpu-tijd, dus geen unix load, die ging naar 3+ toen.
Door
mcv,
woensdag 09 juni 2010 10:34
Waarmee monitoren jullie de omgeving eigenlijk?
Door
SPee,
woensdag 09 juni 2010 11:05
Overcapaciteit is ook handig voor groei.
Kun je meer bezoekers aantrekken (ik neem aan dat jullie dat willen) zonder dat het direct nodig is om hardware bij te plaatsen.
Kun je meer bezoekers aantrekken (ik neem aan dat jullie dat willen) zonder dat het direct nodig is om hardware bij te plaatsen.
Door
mboy,
woensdag 09 juni 2010 21:25
Wat denkt iedereen toch heerlijk traditioneel... Spammen is niet netjes, dus daar zal ik maar niet aan beginnen, maar er zijn, ook in Nederland, al meerdere providers die diensten aanbieden in 'the cloud' die je on-demand capaciteit aanbieden. Uiteraard is het fijn te weten dat je genoeg capaciteit hebt om piekbelastingen op te vangen, maar het is toch jammer dat al die dure capaciteit over het algemeen niks staat te doen... Dat zou je ook kunnen oplossen door alleen te betalen als je de extra capaciteit ook daadwerkelijk nodig hebt.
Spammen is niet netjes, dus daar zal ik maar niet aan beginnen, maar er zijn, ook in Nederland, al meerdere providers die diensten aanbieden in 'the cloud' die je on-demand capaciteit aanbieden. Uiteraard is het fijn te weten dat je genoeg capaciteit hebt om piekbelastingen op te vangen, maar het is toch jammer dat al die dure capaciteit over het algemeen niks staat te doen... Dat zou je ook kunnen oplossen door alleen te betalen als je de extra capaciteit ook daadwerkelijk nodig hebt.[Reactie gewijzigd op woensdag 09 juni 2010 21:26]
Door
ACM,
woensdag 09 juni 2010 21:47
Dat werkt echter wel enkel als je applicatie/omgeving er op ingericht is. Wij hebben nu naadloos deze capaciteit ter beschikking, zonder applicaties en/of onderdelen te hoeven herstarten of op een 'grotere VM' te moeten draaien.
Maar het kan natuurlijk zijn dat jij een hot-plug architectuur hebt met extra of snellere cpu's, snellere disks en extra geheugen dat automatisch beschikbaar is voor je MySQL-server? Waarschijnlijk niet, want vziw kan MySQL helemaal niet on-the-fly zijn bufferpool vergroten en data 'ineens' op een sneller disk-systeem hebben betekent op zijn minst dat je het eerst hebt moeten kopieren/verplaatsen alvorens het 'daar' te hebben. En dat heeft uiteraard een stuk extra belasting gehad op je overbelaste systeem.
Hoedanook, ik denk niet dat je met dezelfde eenvoudige architectuur op onze relatief kleine schaal zo makkelijk voor dergelijke cruciale elementen zomaar capaciteit bij kan schakelen zonder stukken software down te halen. Als je uiteraard alles met dynamische scale-out in gedachten overal helemaal rekening mee gehouden hebt... ja dan zou je met een cloud-omgeving onderdelen aan en uit kunnen zetten naar gelang je belasting het vereist. Dat is inderdaad hoe grote jongens als Google het doen.
Maar het kan natuurlijk zijn dat jij een hot-plug architectuur hebt met extra of snellere cpu's, snellere disks en extra geheugen dat automatisch beschikbaar is voor je MySQL-server? Waarschijnlijk niet, want vziw kan MySQL helemaal niet on-the-fly zijn bufferpool vergroten en data 'ineens' op een sneller disk-systeem hebben betekent op zijn minst dat je het eerst hebt moeten kopieren/verplaatsen alvorens het 'daar' te hebben. En dat heeft uiteraard een stuk extra belasting gehad op je overbelaste systeem.
Hoedanook, ik denk niet dat je met dezelfde eenvoudige architectuur op onze relatief kleine schaal zo makkelijk voor dergelijke cruciale elementen zomaar capaciteit bij kan schakelen zonder stukken software down te halen. Als je uiteraard alles met dynamische scale-out in gedachten overal helemaal rekening mee gehouden hebt... ja dan zou je met een cloud-omgeving onderdelen aan en uit kunnen zetten naar gelang je belasting het vereist. Dat is inderdaad hoe grote jongens als Google het doen.
[Reactie gewijzigd op woensdag 09 juni 2010 21:48]
Door
mboy,
woensdag 09 juni 2010 22:21
mwah, in mijn ervaring zijn bestaande architecturen over het algemeen best wel goed over te zetten naar een cloud based architectuur zonder veel aan te hoeven passen. Wat op traditionele infrastructuren mogelijk is, is in de cloud over het algemeen prima over te nemen.
De manier waarop je het opschalen van capaciteit beschrijft lijkt mij in de praktijk niet mogelijk nee (althans, ik heb het nog nooit voorbij zien komen). Je gaat dan naar het horizontaal opschalen van servers (scale-out idd) en daar is in principe ontzettend veel mee te bereiken, je moet alleen even af durven stappen van de manier over hoe je nu over je internet infra denkt. Overigens hoef je geen grote jongen te zijn hoor, dat is, mits je gebruik maakt van bestaande IaaS providers, best heel prima te betalen.
De manier waarop je het opschalen van capaciteit beschrijft lijkt mij in de praktijk niet mogelijk nee (althans, ik heb het nog nooit voorbij zien komen). Je gaat dan naar het horizontaal opschalen van servers (scale-out idd) en daar is in principe ontzettend veel mee te bereiken, je moet alleen even af durven stappen van de manier over hoe je nu over je internet infra denkt. Overigens hoef je geen grote jongen te zijn hoor, dat is, mits je gebruik maakt van bestaande IaaS providers, best heel prima te betalen.
Ik denk wel dat het kan, ik zie het dagelijks prima werkenHoedanook, ik denk niet dat je met dezelfde eenvoudige architectuur op onze relatief kleine schaal zo makkelijk voor dergelijke cruciale elementen zomaar capaciteit bij kan schakelen zonder stukken software down te halen.