Wat is SaaS-responstijd?

SaaS-responstijd is de gehele tijdsperiode die begint wanneer een gebruiker een dienst aanroept en eindigt wanneer de software het uiteindelijke antwoord geeft. Het is een primaire latentie-meetwaarde waaruit de gebruikersperceptie van de snelheid van het product wordt afgeleid.

Snelheid is sterk gekoppeld aan al deze aspecten: gebruikerstevredenheid, betrokkenheid en de inkomsten van een bedrijf.

• Afgebroken checkout: 40% van de gebruikers verlaat een site die er meer dan 3 seconden over doet om te laden. Tijdens het betaalproces is deze “frictie” nog kostbaarder.
• API-time-outs: Als uw SaaS een betalingsgateway aanroept en de reactie de “timeout”-drempel overschrijdt, faalt de transactie, zelfs als de gebruiker voldoende saldo heeft.
• Dubbelklikrisico: Trage feedbackloops leiden er vaak toe dat gebruikers meerdere keren op “Betalen” klikken, wat resulteert in dubbele transacties en hogere ondersteuningskosten.
• klantenbinding: Het tevreden houden van klanten door de responstijd te minimaliseren, is een van de belangrijkste drijfveren voor het verhogen van retentie en daarmee voor het duurzame succes van het bedrijf.

Om prestaties grondig te doorgronden, is het raadzaam om verschillende monitoringmiddelen te gebruiken die samen het prestatiebeeld compleet maken.

1. Gebruik de Application Performance Monitoring (APM) om de backend-knelpunten te identificeren.
2. Gebruik gedistribueerde tracing om specifieke verzoeken te volgen (wanneer deze door verschillende microservices gaan).
3. Gebruik synthetische controles om gebruikerspaden te simuleren en te testen.
4. Real-User Monitoring (RUM) is een monitoringsmethode die informatie verzamelt over de werkelijke gebruikerservaringen.
5. Gebruik van dashboards voor datavisualisatie. De focus moet liggen op historische baselines en latentie gemeten op de percentielen.

Voor het beoordelen van de transactielevenscyclus, houd rekening met: 

• Transactielatentie: Het bijhouden van de tijd vanaf “Klik op Betalen” tot “Succes/Mislukt”-melding.
• Prestaties van gateway van derden: Het monitoren van de responstijden van externe betalingsverwerkers en belasting-engines.

Veel met elkaar verweven factoren beïnvloeden de responssnelheid (van de efficiëntie van geschreven code tot externe factoren zoals netwerkomstandigheden).

• Infrastructuur: Tot deze factoren behoren serverbelasting, databaseprestaties en de juiste dimensionering van de operationele omgeving.
• Netwerk: Netwerklatentie, samen met de geografische locaties van gebruikers en servers, is vaak een belangrijke factor.
• Architectuur: Variaties kunnen verband houden met architectonische elementen zoals cachingtechnieken, integratiepraktijken van derden en de aanwezigheid van een 'noisiest neighbor' effect in multi-tenant omgevingen.
• Cloudvariabelen: De cloudprestaties veranderen als gevolg van de verschillen in cloudregio's.

Het behalen van de gewenste resultaten vereist een gedegen prestatiedoelplan, en men moet de prestaties regelmatig testen.

• Doelstellingen: Gebruik Service Level Objectives (SLO's) om het acceptabele prestatieniveau te definiëren.
• Waarschuwingen: Stel waarschuwingen in waarop actie kan worden ondernomen en die gekoppeld zijn aan bedrijfskritische diensten wanneer drempels worden overschreden.
• Testen: Voer regelmatig prestatietests uit, uitgevoerd onder belasting, en stel prestatiebudgetten op.
• Onderhoud: Voer regressietesten uit om snel prestatieverminderingen op te sporen en implementeer capaciteitsplanning om in de toekomst aan de vraag te kunnen voldoen.​‍​‌‍​‍‌​‍​‌‍​‍‌

Effectieve​‍​‌‍​‍‌​‍​‌‍​‍‌ alarmering draait volledig om de daadwerkelijke impact op de gebruiker en het tot een minimum beperken van verstoringen.

1. Latentiewijzigingen kunnen de eindgebruiker beïnvloeden; daarom kan het aanpassen van alarmeringsmechanismen voordelig zijn..
2. Wanneer u waarschuwingen instelt, is het een goed idee om uw systeem zo in te richten dat u een melding krijgt wanneer zich afwijkende incidenten (bijv. p95 of p99) voordoen.
3. Houd bij hoe snel u uw prestatiebudget verbruikt. Dit voorkomt SLA-schendingen en financiële boetes die vaak voorkomen in enterprise SaaS-contracten.
4. Stel waarschuwingen in per regio. Een piek in Azië heeft misschien geen invloed op uw wereldwijde gemiddelde, maar kan betekenen dat uw gelokaliseerde betaalmethoden voor een hele markt falen.
5. Activeer waarschuwingen alleen als de latentie 3-5 minuten hoog blijft. Dit filtert tijdelijke netwerk “hiccups” eruit en vermindert waarschuwingsmoeheid voor uw DevOps team.