Als .NET software Developer en Databasebeheerder werk ik bij Topicus aan VIPLive, een verzekerdeninformatiesysteem voor huisartsen en zorggroepen. Afgelopen tijd merkte ik hoge pieken in de CPU-belasting op bij bepaalde onderdelen van VIPLive en het viel mij op dat er soms enorm veel rekenkracht nodig was voor bepaalde processen in het systeem. We waren op dat moment ook net overgestapt van on-premise hosting naar AWS in de Cloud en vrij snel zag ik dat 50% van de rekenkracht werd gebruikt door een achtergrondproces. We hadden genoeg resources om dat aan te kunnen, maar het viel me wel op dat het een flink beslag legde op onze capaciteit. 

Aan de slag met dit issue tijdens “Doe-je-ding-dag” 

Voor mij een mooi vraagstuk om mee aan de slag te gaan tijdens “Doe-je-ding-dag” (een soort hackathon-dag). Het betrof een specifiek stukje code dat niet te groot was, en ik had al wat ideeën over hoe ik het kon verbeteren. Zo kwam ik tot het inzicht dat er veel informatie gesynchroniseerd werd, welke elk kwartaal gecontroleerd dient te worden. Wat mij opviel, was dat er soms een heel klein beetje informatie werd opgehaald en vervolgens heel veel. Telkens werd de informatie opnieuw naar de database gebracht om te verwerken. Dat zorgde ervoor dat we onnodig vaak database queries uitvoerden. 

Ik zag een vergelijking met Max Verstappen die in zijn raceauto een klein boodschappentasje meeneemt. Hij rijdt wel snel, maar moet veel rondjes maken om alles te vervoeren. Vanuit dat idee wilde ik efficiënter omgaan met de data. In plaats van telkens kleine beetjes informatie op te halen, besloot ik grotere hoeveelheden in één keer op te vragen. Maar ook daar zit een valkuil: als je te veel data ophaalt, zoals een groot containerschip vol met spullen die je niet nodig hebt, ben je alsnog inefficiënt bezig. 

Middenweg: een vrachttrein. Die is sneller dan een containerschip en kan nog steeds veel meenemen. Ik heb goed gekeken naar welke informatie we precies nodig hebben, en haalde dat in één keer op. Daardoor konden we veel sneller werken en hadden we minder impact op de andere processen. 

De CPU-tijd terugbrengen van 28 seconden naar 13 milliseconden per minuut! 

Hierdoor heb ik de CPU-tijd van het achtergrondproces weten te verminderen van 28 seconden naar 13 milliseconden per minuut. Het voordeel is dat de database nu minder belast wordt en er minder informatie over het netwerk wordt verstuurd. Ook hebben de servers aan de andere kant minder informatie te verwerken en is de responstijd van de applicatie gedaald. We hebben de hardware met een kwart kunnen afschalen en hebben dus minder hardware nodig om hetzelfde resultaat te bereiken. 

Investeer in goede monitoring; inzicht in bottlenecks is essentieel voor duurzame oplossingen. 

Wat ik van dit proces heb geleerd, is het belang van goede monitoring met DataDog Application Performance Monitoring (APM, https://docs.datadoghq.com/tracing/). We konden grafieken zien die aangaven dat er ergens druk werd gewerkt, maar we wisten eerst niet waarmee. Dit kun je deels oplossen met extra hardware, maar ik vind het juist interessant om te ontdekken waar de bottleneck zit. Zonder die monitoring software hadden we dit specifieke probleem waarschijnlijk nooit kunnen traceren. 

We zagen bijvoorbeeld veel locking in de database bij bepaalde tabellen, maar wisten niet direct dat dit gerelateerd was aan het proces. Als databasebeheerder werk ik al jaren met de opensource scripts van SQL-Server-First-Responder-Kit. Hieruit kon ik herleiden dat er langdurige transacties openstonden. Gecombineerd met gegevens uit APM was dit een perfecte match. Op de grafieken van AWS-database monitoring was mooi te zien dat het aantal openstaande taken stabiel en laag bleef. Met het herschrijven van de code en queries is de hoeveelheid locking geen beperkende factor meer. 

Tips: 

• Wat verbruikt in jouw applicatie de meeste rekenkracht of het meeste geheugen? Pak per release slechts één performanceprobleem aan. Zo weet je zeker dat er geen onverwachte bijeffecten zijn. Dit maakt je applicatie schaalbaar en stelt je in staat om piekbelasting op te vangen of hardware af te schalen. Met betere performance als gevolg. 

• Onderzoek waar de bottleneck zit. Haal vervolgens alleen de informatie op die je nodig hebt voor de verwerking ervan en probeer dat in één keer te doen in plaats van herhaaldelijk naar de database te gaan. In de Cloud zijn veel servers, routers en koelinstallaties aan het werk voor jouw applicatie. Probeer dus, in het kader van duurzaamheid, zoveel mogelijk 'bit-waste' te voorkomen. 

• Houd database-transacties ook zo kort mogelijk. Zorg ervoor dat transacties binnen een seconde worden afgerond, zodat ze niet in de weg zitten. 

• Zorg dat je altijd de nieuwste .NET-versie gebruikt. In elke nieuwe versie zitten verbeteringen die vanzelf voor een betere performance zorgen. Stephen Toub maakt jaarlijks verslag van de belangrijkste wijzigingen in zijn blogs. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/ 

• Blijf meten, testen en leren. Voor micro benchmarks kun je https://benchmarkdotnet.org/ gebruiken. David McArthur heeft in zijn boek "Rock Your Code" allerlei applicatie-voorbeelden gericht op performance. 

   

Pas op voor “gold plating” 

Een valkuil is misschien wel het zogeheten "gold plating". Je kunt altijd blijven verbeteren, maar als het grootste probleem al is opgelost, dan is het goed om niet verder te gaan. Stel hiervoor met je team Service Level Objective (SLO) afspraken op. En maak deze wat strenger dan de Service Level Agreement met de klant. Voldoe je aan de SLO, dan kun je stoppen.