Performancewinst

Enorme performance winst dankzij slimme aanpassingen

Onlangs heb ik bij een groot internationaal bedrijf met in totaal ruim 100.000 medewerkers in de advisory, audit en tax meegewerkt aan een belangrijk project. Voor één van hun klanten is een aangepaste versie van een intern ontwikkeld systeem gemaakt en opgeleverd. Dankzij een aantal aanpassingen kan er nu binnen een team samengewerkt worden aan dossiers en is er een enorme performance-verbetering gerealiseerd. Niet alleen voor het aangepaste systeem, maar ook systemen van andere klanten die op dezelfde servers draaien zijn veel sneller dankzij het afgenomen dataverkeer.

Samenwerken aan dossiers

Het systeem dat ik heb aangepast is ontwikkeld om een controleproces te administreren en de voortgang en resultaten ervan inzichtelijk te krijgen. Binnen dit systeem kunnen dossiers met vragen worden aangemaakt die vervolgens aan behandelaars gekoppeld worden. Afhankelijk van de rol van een behandelaar zijn hier rechten aan gekoppeld. Zoals het invullen of het beoordelen van vragenlijsten.

Een van de belangrijkste aanpassingen die ik gedaan heb, is het mogelijk maken om als team aan een dossier te werken. Dossiers kunnen binnen een team nu heen en weer geschoven worden. Hier was het systeem in beginsel niet voor gebouwd; van origine werden individuele mensen in een rol aan een dossier gekoppeld en niet hele teams van mensen met gedeelde to-do-lijsten. Met wat slimme aanpassingen – onder andere het toevoegen van verborgen statusvragen en door slim gebruik te maken van de uitgebreide filtering die al wel in het systeem zat – is het echter prima gelukt om te voldoen aan de wensen van de klant.

Een nadelig bij-effect van deze door de originele systeembouwers niet voorziene manier van bijhouden en opzoeken van dossiers, was een enorm verlies aan performance. Direct na de aanpassingen en het inlezen van de brondata, wat overigens ook behoorlijk meer was dan ooit voorzien voor dit systeem, bleek er bijvoorbeeld een overzichtspagina in het systeem te zijn die tegen de twee minuten (!) nodig had om zijn werk te doen tegenover een aantal seconden in een normale situatie.

6000% performance winst

Uiteindelijk zijn we er in geslaagd om de oorzaken hiervoor te vinden en de bijna twee minuten terug te brengen naar tussen de 0.2 en 1.5 seconden. Tevens is de belasting op de - met andere systemen gedeelde - servers nu flink verminderd.
De voornaamste issues waren:
Paginering voor een data-grid.
Deze werd op de webserver uitgevoerd waardoor altijd alle data van alle dossiers moest worden opgehaald in plaats van slechts tien(-tallen) stuks
Enorm hoeveelheid data.
Door het aantal toewijzingen van mensen aan rollen in dossiers worden ruim een miljoen records in plaats van enkele tienduizenden ge-query-d.
Een query die eenmaal per dossier liep, in plaats van eenmaal voor alle dossiers.
In combinatie met eerder genoemde paginerings-issue zorgde dit voor meer roundtrippen naar de database server
Te vroeg materialiseren van LINQ-queries.
Dit zorgde voor ophalen van onnodige meer resultaten en extra roundtrip naar de database server.

De oplossing

De oplossing is vervolgens in twee fases doorgevoerd:

Refactoring en quick wins

- Methode waarin de benodigde data werd opgehaald, gesorteerd en gefilterd, met een lengte van honderden regels, opgebroken in kleinere methodes met een beperkter functie. Dit maakte het makkelijker om de rest van het werk te doen en de performanceknelpunten boven tafel te krijgen.
- Onnodige calls naar .ToArray(), .ToList() e.d. weggehaald en queries samengevoegd waar dit makkelijk kon om het aantal roundtrips naar de database server zo veel mogelijk te doen dalen.
- Nalopen van de indexing op SQL server: Toevoegen van missende indexes en defragmenteren van de oude indexes. Na het afronden van deze werkzaamheden draaide deze pagina weer binnen ongeveer 10 seconden.

Overige verbeteringen

- Aanpassen dat paginering, filtering en sortering in zijn geheel op de databaseserver plaats kon hebben.
- Ophakken van de query om de extra metadata alleen op te halen bij te tonen dossiers. Zo worden niet meer voor alle dossiers extra metadata opgehaald, maar alleen voor de daadwerkelijk op de huidige pagina getoonde dossiers.
Na het afronden van deze werkzaamheden draaide de pagina binnen de huidige 0.2-1.5 seconden. Deze variatie komt door het feit dat het systeem nu doorheeft dat uit de “voorselectie” geen/minder rijen terugkomen en vervolgens dus ook überhaupt geen extra metadata op zal gaan halen.

Deze performance verbeteringen hielpen de klant enorm. Men kan nu zijn of haar werkvoorraad weer in secondes inzien in plaats van twee minuten. Alle andere pagina’s binnen het systeem – en ook systemen van andere klanten, die op dezelfde servers draaien – zijn nu sneller door het afgenomen dataverkeer van deze applicatie.

Maarten Alleman, Software Architect / Developer