Webapplicatie ineens traag? Zo vindt u de echte oorzaak

Een orderportaal dat normaal meteen reageert, heeft ineens vijf seconden nodig om één klant op te zoeken. Medewerkers klikken nog een keer, klanten haken af en bij support gaat de telefoon. Op dat moment is een trage webapplicatie geen technisch detail meer, maar iets dat omzet, productiviteit en vertrouwen raakt.

De eerste reflex is vaak om naar de hosting te wijzen. Soms klopt dat. Veel vaker zit de oorzaak in het samenspel van applicatiecode, database, externe koppelingen en een gebruik dat ongemerkt veranderd is. Wie direct extra servercapaciteit bijkoopt zonder te meten, dempt in het beste geval het symptoom. De bottleneck blijft dan staan en meldt zich over een paar weken opnieuw. Een halve dag gericht onderzoek is bijna altijd goedkoper dan een maand gokken.

Waar gaat de tijd verloren?

Bij een plotselinge vertraging is de interessante vraag niet hoeveel seconden een pagina nodig heeft, maar waar die seconden blijven. Een webapplicatie is een keten: de browser van de gebruiker, het netwerk, de webserver, de applicatiecode, de database, bestandsopslag en vaak nog een rij externe API’s. Eén trage schakel remt het geheel af, ook als alle andere schakels gezond zijn.

Let op: ‘plotseling’ betekent niet dat er vlak daarvoor iets groots gewijzigd is. Een inefficiënt proces kan maanden onzichtbaar meedraaien en pas opvallen zodra het aantal orders, gebruikers of records een bepaalde grens voorbij groeit. Een zoekfunctie die bij tienduizend klanten prima werkt, kan bij een miljoen records onderuit gaan. Datzelfde geldt voor rapportages, nachtelijke imports en achtergrondtaken die stilletjes capaciteit opeten. Groei is dus ook een wijziging, alleen een langzame.

Drukte is niet hetzelfde als te weinig capaciteit

Meer bezoekers of meer ingelogde medewerkers kunnen een systeem afremmen, maar drukte is niet automatisch de oorzaak. Een goed ingerichte omgeving vangt pieken op binnen de marges die u met uw leverancier hebt afgesproken. Het gaat mis wanneer rekenkracht, geheugen, schijfsnelheid of het aantal databaseverbindingen niet meer past bij de manier waarop de applicatie inmiddels gebruikt wordt.

Kijk daarom eerst naar het patroon. Is het alleen traag rond openingstijd, na een nieuwsbrief of tijdens de dagelijkse import? Dan is belasting een logische verdachte. Is het de hele dag traag, ook bij simpele handelingen en ook als er bijna niemand werkt? Dan denkt u eerder aan een vastgelopen proces, een hapering in de opslaglaag of een fout in de applicatie zelf.

De database is vaak de stille rem

Veel zakelijke webapplicaties raken bij vrijwel elke handeling de database. Voorraad tonen, klantgegevens laden, rechten controleren, een dashboard opbouwen: het loopt allemaal langs dezelfde kant. Zodra een query te veel rijen doorloopt, ontbrekende indexen heeft of staat te wachten op een andere transactie, loopt de wachttijd hard op.

Dat valt het hardst op bij pagina’s die veel tegelijk ophalen. Een dashboard met tientallen tegels, grafieken en totalen vuurt soms honderd losse vragen op de database af. Geen probleem, zolang elke vraag goedkoop is. Groeit één tabel, verandert een relatie of loopt de nachtelijke verwerking door tot in de ochtend, dan kantelt zo’n pagina van vlot naar onbruikbaar.

Een zwaardere databaseserver is daarbij zelden het eerste antwoord. Soms is één index genoeg. Soms moet een query anders geschreven worden, of moeten gegevens anders worden opgeslagen. Bij zware rapportages kan het slim zijn om cijfers vooraf uit te rekenen en klaar te zetten, zodat de pagina alleen nog hoeft te lezen. Dat is wel een ontwerpkeuze: u ruilt een stukje actualiteit en onderhoudsgemak in voor snelheid. Een financieel overzicht van gisteren is prima. Een voorraadstand van gisteren niet. De keuze moet dus passen bij het proces, niet bij de techniek.

Externe koppelingen maken u afhankelijk

Betalingen, boekhouding, CRM, verzenddiensten, inlogproviders en voorraadbeheer hangen vaak via API-koppelingen aan uw applicatie. Reageert zo’n dienst traag, zit u tegen een limiet aan of geeft de leverancier tijdelijk fouten terug, dan kan uw applicatie daar geduldig op blijven wachten.

De gebruiker ziet dan een trage pagina, terwijl uw eigen servers nergens overbelast zijn. Daarom wilt u per externe aanroep weten hoe lang die duurde en wat er gebeurde bij een fout. Zonder die meting zoekt u in de verkeerde hoek. Stel bovendien een timeout in die korter is dan het geduld van uw gebruiker, met een begrijpelijke melding op het moment dat die timeout wordt gehaald.

Soms kan werk naar de achtergrond. Een bestelling slaat u eerst veilig op en bevestigt u aan de klant, waarna de koppeling met de boekhouding in een wachtrij volgt en automatisch opnieuw probeert als het misgaat. De klant wacht dan niet op een systeem waar u geen invloed op heeft. Daar hoort wel iets tegenover te staan: zichtbare statussen, nette foutafhandeling en iemand die kijkt naar wat blijft hangen. Zonder dat verplaatst u het probleem van snelheid naar datakwaliteit, en dat is de duurdere van de twee.

Zo achterhaalt u de oorzaak

Begin met een tijdlijn, niet met een theorie. Wanneer begon het, welke onderdelen zijn geraakt en wat is er rond dat moment veranderd? Denk aan een release, een aangepaste DNS-instelling, een grotere import, een mailing die uitging, een nieuwe groep gebruikers of onderhoud bij een leverancier. Vindt u niets? Dan is dat ook informatie. Kijk dan naar geleidelijke groei en naar taken die op een vast tijdstip draaien.

Controleer daarna of iedereen hetzelfde ervaart. Eén trage werkplek wijst richting lokaal netwerk, browserextensies, VPN of het apparaat zelf. Is het voor iedereen traag, dan zoekt u centraal. Test niet de homepage, maar precies de handelingen waarmee het werk stilvalt: inloggen, zoeken, opslaan, afrekenen, een rapport openen.

En meet. Serverbelasting, geheugengebruik, vrije schijfruimte, foutmeldingen, responstijden van databasequery’s en wachttijden bij externe diensten. Applicatielogs vertellen welk verzoek langzaam was en hoe vaak dat gebeurt. Monitoring laat zien of u naar een eenmalig incident kijkt of naar een patroon dat elke dinsdagmiddag terugkomt.

Splits de totale laadtijd vervolgens op in vier stukken: tijd in de browser, tijd op het netwerk, tijd in de applicatie en tijd in de database of bij externe koppelingen. Die verdeling voorkomt dat iemand dagen bezig is met het verkleinen van afbeeldingen terwijl de vertraging bij de betaalprovider zit.

Wat u tijdens een storing beter laat

Een trage applicatie nodigt uit tot snelle ingrepen, en juist die maken het vaak erger. Services blijven herstarten geeft even lucht, maar wist het bewijs dat u nodig heeft en kan lopende processen halverwege afbreken. Haastig caching aanzetten is ook geen gratis winst. Caching is een prima maatregel, maar wel één die u met een plan en een doordachte vervaltijd neemt, niet iets wat u in paniek over de hele applicatie uitrolt terwijl gebruikers juist actuele voorraad, prijzen en statussen moeten zien.

Grote codewijzigingen midden in een incident zijn alleen verdedigbaar als de oorzaak vaststaat en u de wijziging gecontroleerd kunt uitrollen en terugdraaien. Eerst stabiliseren, daarna structureel verbeteren, is bijna altijd de veiligste volgorde. Communiceer intussen gewoon eerlijk: wat werkt niet, waar wordt aan gewerkt en wanneer volgt het volgende bericht. Stilte levert meer onrust op dan een korte statusmelding zonder oplossing.

Van incident naar controle

Een oplossing is pas een oplossing als u kunt laten zien waarom ze werkt. Query aangepast? Zet de responstijd van voor en na naast elkaar. Capaciteit uitgebreid? Controleer of de piek nu binnen veilige marges blijft en leg vast waar de nieuwe grens ligt. Externe API de boosdoener? Schrijf op welke timeout, fallback of wachtrij voorkomt dat uw eigen proces nog een keer vastloopt.

Voorkomen draait om zichtbaarheid en eigenaarschap. Alleen beschikbaarheid meten is te mager, want een applicatie kan vrolijk melden dat ze online is en toch onwerkbaar aanvoelen. Meet daarom de paar flows waar uw bedrijf op draait, plus databaseprestaties, foutpercentages en de responstijden van systemen van derden. Zet daar grenswaarden op, zodat iemand ingrijpt voordat de eerste gebruiker belt.

Verantwoordelijkheid is het andere stuk. Liggen development, hosting, databasebeheer en integraties bij vier partijen, dan gaat de eerste dag van een incident op aan de vraag wie aan zet is. Een partner die de hele keten kent, analyseert sneller en repareert gerichter. Bij LJPc liggen ontwikkeling en hosting daarom bij één technische verantwoordelijke, zodat een incident niet tussen leveranciers blijft hangen.

De handigste vervolgstap is klein: bepaal welke drie handelingen in uw webapplicatie bedrijfskritisch zijn en meet die structureel. Zodra u weet hoe normaal eruitziet, ziet u afwijkingen vroeg. Plotselinge traagheid wordt dan een beheersbaar incident in plaats van een dag giswerk.