Opschalen/uitbreiden? Of echte prestatieproblemen…

Gepubliceerd op 13 januari 2011 • 3 min leestijd • 608 woorden
Ik las vandaag een ander artikel over cloud computing. Bijna alle artikelen en berichten lijken zich te concentreren op hoe gemakkelijk het is om…

Ik las vandaag een ander artikel over cloud computing. Bijna alle artikelen en berichten lijken zich te concentreren op hoe gemakkelijk het is om bronnen aan uw omgeving toe te voegen wanneer u meer stroom nodig heeft.

Voordat je mij gaat uitleggen waarom dit waar is: ja, ik ben het ermee eens. Het is heel eenvoudig om resources toe te voegen aan een bestaande omgeving. Wanneer u vSphere, Hyper-V of XenServer gebruikt, voegt u gewoon een andere host toe aan uw cluster of datacenter en beschikt u over meer vermogen dat door uw machines kan worden gebruikt. Je kunt virtuele machines meer CPU-kracht en/of geheugen geven, etc. Uiteindelijk hebben je applicaties (dat is uiteindelijk het belangrijkste) meer kans om op een gedeelde omgeving te draaien.

Mijn probleem met deze aanpak is simpel: doen we de dingen niet op de verkeerde manier?

Moeten we het probleem niet oplossen?

We accepteren de huidige manier om de omgeving uit te breiden met extra middelen in plaats van echte probleemoplossing uit te voeren en met de vinger te wijzen.

Als u merkt dat uw toepassing traag is, zoek dan eerst uit waarom deze traag is, in plaats van dat u bronnen toevoegt. Ik herinner me een probleem met een documentbeheersysteem dat niet functioneerde. “Het is niet geschikt voor virtualisatie”, was het eerste wat de DBA zei. Nadat we ze een fysieke server hadden gegeven, zeiden ze: “De manier waarop je Windows automatisch installeert is onjuist, er zit iets in dat de server vertraagt”. Je raadt het al, we hebben de server handmatig geïnstalleerd en het probleem bestond nog steeds.

Na wat echte probleemoplossing kwam de DBA erachter dat ze één index in de database hadden gemist. Nadat de index was gemaakt, verliep alles zo soepel als je zou verwachten.

Een paar weken geleden was ik met een andere bezig

Het lijkt mij dat dit gebeurt sinds het begin van het x86-platform. Toen we voor het eerst met computers begonnen, riep iemand: “640k is genoeg”. Die dagen zijn al lang voorbij. Zelfs met 640 MB intern geheugen kom je niet ver, tenzij je iets anders dan Windows gebruikt.

Nu ben ik geen ontwikkelaar van beroep, hoewel ik wel in een paar talen kan programmeren, maar het lijkt mij dat optimalisatie van de applicatie niet erg hoog op de prioriteitenlijst staat. Hoeveel ontwikkelaars kunnen eerlijk zeggen dat ze hun applicatie grondig optimaliseren voordat ze deze verzenden?

Hier volgen enkele tips voor het oplossen van problemen. Het is van hoog niveau, dus geldig voor alle applicaties en platforms.

  • Zorg ervoor dat u (en uw applicatiegebruikers) het over één en hetzelfde onderwerp hebben
  • Weet hoe uw omgeving presteert. Maak basislijnen. Document.
  • Begin met het oplossen van problemen met alle partijen. Als het een client/server-app is, zorg dan dat je ze allemaal hebt: netwerk, opslag, virtualisatie, DBA en eindgebruiker
  • Praat met de applicatie-ontwikkelaar/leverancier. Presteert zijn applicatie zoals het hoort?

Als je dit allemaal hebt gedaan en nog steeds geen prestatieverbetering hebt bereikt, kun je (misschien) wat extra bronnen toevoegen aan je machine of applicatie.

Aan de ontwikkelaars en leveranciers onder ons vraag ik: optimaliseer alstublieft uw applicatie voordat u deze verzendt. In de hele Green IT-discussie denk ik dat dit een geldig punt is. Hoe minder geheugen en bronnen u nodig heeft, hoe minder rekenkracht u nodig heeft. hoe meer bomen je spaart.

Toen ik dit bericht aan het afronden was, wees Erik me op dit artikel dat gaat over kernen en nog meer kernen. De auteur van dit artikel concludeert ook dat meer niet altijd beter is.

Zie ook

    Follow me