ORDINA BLOGT

7 tips voor energiezuinigere software

Het is niet zo ingewikkeld om applicaties energie-efficiënter te maken. Met deze zeven tips kom je al een heel eind.

  • Ton Geurts
  • 25 november 2013

Ik heb al vaker benadrukt dat het belangrijk is dat applicaties energie-efficiënter moeten worden. Uiteindelijk zijn het de applicaties die ervoor zorgen dat de hardware energie gebruikt. Maar hoe doe je dat concreet? Het is niet zo moeilijk. Wees je bewust van hoe een computer werkt en hoe een netwerk werkt. Vraag je bij een ontwerpbeslissing af of het resource-efficiënter kan, gegeven de andere eisen die de opdrachtgever stelt aan de software.

Voor hen die behoefte hebben aan concrete tips, hier volgen er zeven.

Tip 1: Bouw alleen wat nodig is

Hoe groter een applicatie, des te hoger het energieverbruik. Een simpele manier om het energieverbruik te beperken is dan ook om niet meer software te bouwen dan strikt noodzakelijk. Het lijkt een open deur. Toch worden in de praktijk heel veel functionaliteiten gedefinieerd voor een applicatie die niet, of hoogst zelden, worden gebruikt. Maar die functionaliteiten worden wel gebouwd.

Hoe komt dat dan? Het ligt vaak aan methodiek die wordt gebruikt voor de ontwikkeling van de applicatie. De opdrachtgever voor een nieuwbouwproject wil graag vooraf weten wat alles gaat kosten. Dus wordt er met man en macht nagedacht over wat de applicatie eventueel allemaal zou moeten kunnen doen, want later toevoegen is duur. Dat leidt tot overspecificatie: er worden meer functionaliteiten bedacht dan eigenlijk gewenst zijn (dat is ook duur).
Applicaties die ontwikkeld worden met een iteratieve methode, zoals agile/scrum, hebben die vervelende eigenschap minder. Daar wordt iedere paar weken bepaald welke functionaliteiten dan gewenst zijn. Daarmee voorkom je dat je op voorhand gaat overvragen en daardoor teveel gaat bouwen. Er wordt dan minder energie verspild.

Tip 2: Laad alleen wat ook wordt gebruikt

Met al die teveel gedefinieerde functionaliteiten duurt het opstarten van een applicatie onnodig lang en is het energieverbruik onnodig hoog. Dit kan je ondervangen door software modulair te bouwen en modules alleen in het computergeheugen te laden als deze daadwerkelijk worden gebruikt. Wordt een module een tijdje niet meer gebruikt? Verwijder hem dan maar weer uit het geheugen. Het is net als in een kamer. Je doet alleen het licht aan als je in de kamer bent. Ga je de kamer uit, dan doe je het licht weer uit.

Als je een productcatalogus voor de website onderhoudt, dan heb je die teksteditor alleen nodig als je de uitgebreide productomschrijving aanpast. Een slimme applicatie laadt hem dan ook dan pas. En als die teksteditor een spellingscontrole bevat, laadt het woordenboek dan alleen als er ook daadwerkelijk om spellingscontrole wordt gevraagd. Wordt de teksteditor afgesloten, verwijder hem (en de spellingscontrole) uit het geheugen.

Tip 3: Beperk de resolutie van afbeeldingen

Moderne camera’s maken zonder enig probleem foto’s met een resolutie van 12 megapixels. Dat is 4000x3000 pixels. Een modern scherm heeft resolutie van 1600x1200 pixels. Op een website of een desktop applicatie kan je dus niet de hele foto tonen. Gelukkig kan je op een webpagina aangeven wat de hoogte en breedte van een afbeelding moet zijn, bijvoorbeeld 400x300 pixels. De webbrowser haalt de foto op schaalt deze dan.

Het is veel efficiënter als je die foto op de server opslaat in de benodigde resolutie. Dat scheelt schijfruimte, netwerkverkeer (in het voorbeeld een factor 100!) en processorgebruik en maakt de applicatie sneller.

Tip 4: Denk na over wat je bewaart

Schrijven van data kost ook energie. Net als bij de discussie over functionaliteiten, is het goed om na te denken over welke data je wel nodig hebt, en welke data eigenlijk niet. Als je alleen digitaal communiceert en produceert, waarom zou je dan telefoonnummers en postadressen vastleggen? Alle data die je bewaart gebruikt resources bij het wegschrijven, ophalen en bewaren.

Behalve bedrijfsdata wordt voor onderhoudbaarheid en verantwoording door applicatie informatie gelogd in de event viewer, logfiles of journaling tabellen. Wanneer je iets log (variërend van informatief tot fatale gebeurtenis) en hoe uitgebreid (van alleen metadata tot inhoudelijke businessdata), hangt af van het doel. Tijdens de ontwikkeling wil je sneller iets loggen dan in productie. Maar als het plotseling misloopt in productie wil je het logniveau kunnen aanpassen. Maak dat dus instelbaar.

Tip 5: Beperk netwerkverkeer

Netwerkverkeer is een energiegrootverbruiker. Er zitten vaak meerdere netwerkcomponenten tussen de onderdelen van een applicatie, zeker op internet. Die energie vindt je misschien niet allemaal terug op jouw stroomrekening, maar het wordt wel gebruikt. Wees daarom bedacht op onnodig netwerkverkeer. Een roundtrip van de applicatie naar de database om 1.000 records op te vragen is aanzienlijk goedkoper in energieverbruik dan duizend roundtrips om steeds één record op te vragen.

Tip 6: Bouw platformspecifiek

Er zijn tegenwoordig veel ontwikkelplatforms waarop je snel en zonder een programmeur te zijn, apps kunt ontwikkelen voor allerlei platformen. Dergelijke ontwikkelplatforms maken gebruik van meerdere abstractielagen. En hoewel apps hierdoor snel kunnen worden ontwikkeld, gebruikt iedere abstractielaag extra energie. Daarnaast is het voor zulke platforms niet te doen om gebruik te maken van specifieke eigenschappen van een besturingssysteem.

Platformspecifiek gebouwde software heeft de overhead van die abstractielagen niet en is daarom energie-efficiënter. Het is confectie versus maatwerk.  Je hoeft natuurlijk niet terug te gaan naar het programmeren in assembler, maar het kan geen kwaad om na te denken hoe platformafhankelijk je wilt ontwikkelen.

Tip 7: Compileer code

In geïnterpreteerde ontwikkeltalen, zoals ASP en PHP, wordt code pas bij het aanroepen van de applicatie gecompileerd naar processorinstructies. Tot die tijd is het voor mensen leesbaar. Het voordeel van een geïnterpreteerde taal is dat je de code snel kunt aanpassen. Er gaat iets niet goed op de website? Even de pagina on-the-fly aanpassen en het probleem is verholpen. Er zijn geen opvolgende handelingen nodig, zoals compileren en linken.
Dat is ook gelijk het nadeel: code moet worden gecompileerd naar processorinstructies, anders kan de computer er niets mee. Bij een geïnterpreteerde taal moet de code bij iedere aanroep opnieuw moet worden gecompileerd door de applicatieserver. Met caching is wel wat verbetering te bereiken, maar in plaats van één keer, wordt de code vele malen gecompileerd. En compileren kost energie. Verschillende geïnterpreteerde talen hebben de mogelijkheid om code te precompileren. Het voordeel van code on-the-fly kunnen aanpassen gaat dan wel verloren.

 

Tegen alle argumenten die ik hier noem zijn ook wel tegenargumenten te vinden. Dat is niet erg. Dat hoort ook zo. De software architect moet de voors en tegens van alle aspecten tegen elkaar kunnen afwegen. Energie-efficiëntie hoort daar bij.

Over de auteur:

Ton Geurts

Ton Geurts werkt sinds 2006 bij Ordina. Hij is een maatschappelijk betrokken solution architect. Vanuit dat perspectief schrijft hij over ontwikkelingen in de ICT, met speciale aandacht voor duurzaamheid.