De verborgen kosten van trage applicatiecode

Lees hieronder meer over de verborgen kosten van trage applicatiecode

introductie

Ontwikkelaars krijgen vaak te horen dat ze zich niet moeten concentreren op de prestaties van applicaties voordat deze nodig is (om voortijdige optimalisatie te voorkomen). En dat een productieve taal (weinig moeite van de ontwikkelaars om de code te produceren) belangrijker is dan een taal die snelle code produceert omdat de tijd die de ontwikkelaar besteedt aan het schrijven van de code zo duur is. Het idee is dat wanneer een code in productie snel genoeg draait om op tijd zijn werk te doen, het dan goed is. Men kan vasthouden aan een taal die misschien een lage uitvoeringssnelheid heeft, maar een goede productiviteit.

Dit is natuurlijk vaak erg waar, maar meestal ook niet de volledige waarheid. Veel tijd én geld kan ‘weglekken’ door traag presterende code te accepteren. Vandaar dat we de verborgen kosten van trage applicatiecode uitleggen.

Ontwikkelingskosten

Naast het produceren van codes is de andere activiteit die veel tijd kost voor de developers het testen van code. Testen in de zin van het uittesten van de toepassing direct na een wijziging in de code en dit testen in een CI-pijplijn.

Het eerste geval is waarschijnlijk heel herkenbaar: code wordt bewerkt, druk op de sneltoetsen ‘Uitvoeren’, wacht even tot de applicatie opstart en ga dan verder om te zien of de applicatie doet wat het plan was.

Hoe lang duurt het nu, vanaf het moment dat op die ‘Run’-snelkoppelingscombinatie wordt gedrukt, tot het moment dat gezien wordt of de applicatie zich gedraagt zoals bedoeld? Die specifieke tijd wordt vaak ‘vergeten’ in de redenering voor het kiezen van een programmeertaal/runtime. Deze tijd omvat zowel compilatie als de tijd voor de applicatie om op zijn tempo te doorlopen. De prestaties van de compiler kunnen dus van invloed zijn op die tijdsduur en/of de prestaties van de application code zelf.

Dat laatste geval is misschien wat meer vermomd. De CI-pijplijn dient gewoon op de achtergrond op een server te worden uitgevoerd, zonder het werk van de ontwikkelaar te doorkruisen. In werkelijkheid komt het echter vaak voor dat een ontwikkelaar wacht om te zien wat de nieuwe code doet in alle integratietests die in de CI-pijplijn worden uitgevoerd. De ontwikkelaar is misschien met iets anders bezig, maar is mentaal nog bezig met wat de uitkomst van de tests zullen zijn.

In productie kosten

De uitspraak ‘de prestaties van een applicatie in productie zijn niet erg belangrijk als het de klus snel genoeg klaart’ was vroeger helemaal waar toen alle code op bedrijfseigen of andere speciale hardware draaide. In deze tijd van cloud computing is het vrij gebruikelijk dat de prijs van het draaien van de software in productie sterk afhankelijk is van resourcegebruik in de vorm van CPU-cycli en / of geheugengebruik. Dit betekent dat inefficiënte/trage software vele malen meer kan kosten dan efficiënte/snelle software die dezelfde taak in dezelfde instelling uitvoert. Met de komst van serverless technologie wordt dit alleen maar meer en meer een factor in de TCO (Total Cost of Ownership) van de applicatie.

Oplossingen

Laten we kijken naar oplossingen.

Compileertijd

Op dit aspect kunnen sommige talen die traag zijn bij het uitvoeren een voordeel hebben. Scripttalen met behulp van een interpreter voorkomen bijvoorbeeld dat men wacht tot de compiler is voltooid. Op het gebied van gecompileerde talen is er ook een focus op compiler prestaties door de ontwerpers van een aantal van de nieuwere talen zoals Go en het meer obscure Vlang.

Aandacht besteden aan de compilerprestaties van een specifieke programmeertaal kan veel helpen in de ervaring van de ontwikkelaars en in de totale tijd van de ontwikkelingscyclus.

Looptijd

De run-time prestaties (of kosten) van de toepassing in productie, wordt meestal bepaald door 2 factoren;

  1. Algoritmische efficiëntie van de code. Dit is afhankelijk van de vaardigheid van de ontwikkelaars en de tijd die wordt gegeven om de applicatie te ontwikkelen. Het optimaliseren van code kan veel tijd kosten.
  2. Prestaties van de gecompileerde taal en runtime. Dit wordt bepaald door de taalkeuze voor het project. Dit kan natuurlijk beïnvloed worden door bestaande code, kennis van de ontwikkelaars of andere factoren.

Het kiezen van de juiste balans is hier belangrijk, en wetende dat de runtime-prestaties van invloed zijn op de in-productiekosten en ontwikkelingskosten, helpt veel bij het maken van de juiste keuze.

Testtijd

De prestaties bij het testen (de tijd die nodig is om de tests uit te voeren) worden eigenlijk bepaald door veel factoren, maar laten we eens kijken naar de belangrijkste:

  1. Runtime-prestaties – Beschreven in de vorige sectie en heeft een belangrijke invloed, ook bij het uitvoeren van tests.
  2. Testgegevens set – Het verstandig kiezen van de test set kan een enorme impact hebben op de duur van de test. Stel de set zorgvuldig samen om alles en alleen te bevatten wat getest moet worden.
  3. Testomgeving – Kies de juiste technologieën om de tests uit te voeren in de omgeving die ze nodig hebben. Probeer te voorkomen dat VM’s gebruikt worden voor elke test en kijk naar het gebruik van containers die veel lichter zijn en een fractie van de tijd kosten om te beginnen.
  4. Mock-objects – In het geval van unit-tests is de keuze om mock-objects te gebruiken in plaats van bijvoorbeeld een echte database of bestandssysteem een goede gewoonte, maar kan ook een groot verschil maken in de testprestaties.
  5. De testlogica – Hoe en wat er wordt getest moet ook zorgvuldig worden overwogen om het maximale uit uw test investering te halen.

Conclusie

Er kan veel gewonnen worden bij het maken van de juiste keuzes aan het begin van een softwareproject met betrekking tot programmeertaal, algoritmen en het instellen van testsuites. Het gebruik van cloud computing kan een belangrijke factor zijn omdat het de kostenimpact verandert die slecht presterende code heeft. De ontwikkelingscyclus kan ook op een aantal manieren worden beïnvloed door de prestaties van de code (zowel de toepassing als de compiler).