Hoe maken wij performance meetbaar?

Wat is performance nu eigenlijk?

Performance is een begrip dat gaat over het gevoel van tijd. Elke keer als je ergens in de applicatie klikt, duurt het een bepaalde tijd voordat je verder kan. Dat kan verschillen, van navigeren naar een andere pagina tot alle bewoners op een adres ophalen (kan langer duren bij bijvoorbeeld verzorgingstehuizen).

Als ontwikkelteams werken wij met Scrum en doen wekelijks een refinement. Dit is het moment in de week dat wij een inschatting gaan maken hoe complex een bepaalde klantbehoefte is.

Voor ons als ontwikkelaar denken wij bij deze refinements ook na over, hoe voor de functionaliteit zo min mogelijk extra kliks nodig zijn. Hier komt dus ook de link tussen performance en gebruikerservaring aan bod.

Performance SMART maken

Onze applicatie bestaat uit meerdere lagen met verschillende componenten. Hieronder een overzicht. Alle roze blokken beheren wij en hebben wij invloed op de werking. De blauwe blokken zijn de onderdelen waar de gemeenten invloed op hebben en de paarse blokken zijn de blokken van externe keten partners.

In praktijk zien wij dat onze procesafhandeling onderhevig is aan vele afhankelijkheden. Wij maken onze performance KPI’s specifiek door ons te focussen op het voor ons primair zwaarste component. Meetbaar maken wij het door te kiezen voor de wachttijd van alle kliks in het standaard uitgeleverde proces bij elkaar op te tellen. Acceptabel en Realistisch, wij proberen dagelijks ongeveer gelijke druk uit te oefenen op het component en willen dan ongeveer dezelfde wachttijd zien. Wij focussen er dus op dat de nieuwe gebouwde functionaliteiten geen extra wachttijd veroorzaken. Wat betreft Tijdsgebonden, wij bekijken de resultaten van een week om daarmee de vergelijking tussen releases te kunnen maken. Dit vlakt de resultaten een beetje uit.

Het resultaat van een loadtest kun je ongeveer zo zien, dit is het gemiddelde van de duur van een klik in het proces (klik op afbeelding om te vergroten):

Na het aanmaken van de release gaan wij deze zelfde test ook uitvoeren op onze cloud omgeving met de volledige keten. Hierbij willen wij een vergelijkbaar resultaat zien als bij onze vorige testen. De tijdsduren tussen deze ketentest en de specifieke procesafhandeling kunnen sterk verschillen, daardoor kunnen wij enkel resultaten die op dezelfde wijze zijn uitgevoerd met elkaar vergelijken.  

Wat als een proces trager lijkt te zijn geworden?

In het bovenstaande diagram lijk het alsof Overlijden iets trager is geworden. Dan gaan wij kijken welke stappen precies trager zijn geworden en waardoor deze trager zijn. Dan kunnen wij daarna de keuze maken of dit acceptabel is door toegevoegde functionaliteit of dat wij hier nog een aanpassing in doen om de stappen te versnellen. 

Wij werken momenteel aan deze verbeteringen

• Een nieuwe servicebus en API manager voor onze cloud. Hiermee verwachten wij een betere ontsluitbaarheid, schaalbaarheid, onderhoudbaarheid en snelheid richting externe partijen. Ook hebben wij al gezien dat wij nog een grote verbeterslag kunnen maken in de verbindingssnelheid naar de binnengemeentelijke BRP (Cipers).
• Ook doen we een pilot met een directe verbinding met de cloud van ketenpartners. Hierdoor gaat verkeer direct naar de cloud van de ketenpartner, in plaats van dat deze omgeleid wordt over andere netwerken. 

Zelf invloed hebben op performance? Dat kan!

Daarvoor deel ik de volgende 5 tips met je:

1) iDocumentcreatie
Bij de ontwikkeling van iDocumentcreatie zijn wij volledig opnieuw begonnen om een goede snelle documentcreatietool te maken die goed en snel integreert met onze eigen applicatie. Dit zorgt ervoor dat iBurgerzaken sneller een document genereert. Lees er hier meer over. 

2) iContinuïteitsvoorziening
Maak je nog gebruik van zaakgericht werken in het proces, zonder iContinuïteitsvoorziening? Kijk dan eens naar deze best practice #50. 

3) Controleren stap overslaan
In iBurgerzaken hebben wij vele procesconfiguraties. Denk hierbij bijvoorbeeld aan het overslaan van de controleren-stap. Als deze stap over het algemeen niet wordt gebruikt, kan deze het beste worden uitgezet, dat scheelt weer onnodige kliks. Naast in iVerblijf & Adres is dit ook al ontwikkeld in iVerzoek. Bekijk best practice #43.

4) Juiste browserinstellingen
De impact van de browser op onze applicatie is groot. Als de door jullie gekozen browser met de gekozen instellingen slecht presteert, zal je dat strek terugzien in onze applicatie performance. Best practice #125 gaat daarover.

5) Voldoende capaciteit op je PC
Browsers vragen soms best wel veel van je computer. Denk hierbij aan bijvoorbeeld het weergeven van de kaart met de postcodegebieden in iVerkiezing. Het kan handig zijn om elk jaar een controle te doen of de systemen de druk makkelijk of moeilijk aankunnen. Als het moeizaam gaat, is de kans dat het beter wordt zonder er iets aan te doen klein. Als er computers aangeschaft worden, bedenk dan vooraf: 

• Hoe lang wil ik deze computer gebruiken?
• Hoe ziet het werk van de mederwerker die de computer in gebruik neemt eruit, richting het eind van de gebruiksduur?
• Bevat de beoogde computer voldoende capaciteit om nog goed mee te kunnen richting het einde van de gebruiksduur? 

Neem gerust contact met mij op

Ik hoop hiermee een mooi inzicht te hebben gegeven op onze zicht rondom performance. Heb je vragen? Stuur mij dan gerust een mail. Dit kan via:  Ralph.Hees@PinkRoccade.nl