Uw applicatie is traag en gebruikers klagen? Lees dit voordat u een zwaardere server koopt
De applicatie is traag en de oplossing zou een zwaardere server zijn? Meestal niet. Waar de tijd heen gaat, hoe u meet en wanneer een server helpt.
Vlado Pandžić · Oprichter · Senior .NET-architect
Gepubliceerd · 4 min lezen
Gebruikers klagen. Schermen blijven laden, een rapport duurt twee minuten, en op maandagochtend werkt niets zoals het hoort. Iemand stelt een zwaardere server of een groter cloudabonnement voor. U koopt het, twee maanden gaat het iets beter, en dan is het weer hetzelfde. Alleen is de rekening nu hoger, elke maand.
Dat gebeurt omdat een zwaardere server in de meeste gevallen het antwoord is op de verkeerde vraag.
Waarom een zwaardere server zelden helpt
Stel u een magazijnmedewerker voor die voor elk artikel van een bestelling apart naar het schap loopt en terug. Bij een bestelling van 400 artikelen zijn dat 400 keer heen en weer. U kunt hem een snellere heftruck geven en hij wordt iets sneller, maar de echte oplossing is alles in één keer te pakken.
Bedrijfsapplicaties doen heel vaak precies dat. De meest voorkomende oorzaken van traagheid zitten niet in de kracht van de server, maar in de manier waarop de applicatie werkt:
- Honderden queries voor één scherm. De applicatie vraagt de database voor elke regel apart, in plaats van één keer voor alles.
- Een database zonder de juiste indexen. Om één record te vinden, leest de database de hele tabel. Zolang de tabel klein is, merkt niemand het. Na vijf jaar data merkt iedereen het.
- Rapporten die alles laden. De applicatie haalt alle data in het geheugen en filtert en telt pas daarna, in plaats van dat aan de database over te laten.
- Aanroepen van externe diensten na elkaar. Elke aanroep wacht op de vorige, zodat de seconden optellen.
- Niets wordt onthouden. Data die één keer per dag verandert, wordt bij elk openen van een scherm opnieuw berekend.
Een zwaardere server maakt elk van deze dingen een beetje sneller, en elke maand komt er meer data bij. Daarom komt het probleem altijd terug.
De symptomen vertellen waar u moet zoeken
U hoeft geen ontwikkelaar te zijn om het te beperken. Dit kan een manager zelf opmerken:
| Wat u merkt | Waar het probleem meestal zit |
|---|---|
| Alleen sommige schermen of rapporten zijn traag | In de code of de queries achter die schermen |
| Alles wordt trager naarmate er meer data is | In de database: indexen en de manier waarop data wordt opgehaald |
| Het is traag op bepaalde momenten van de dag | Er draait tegelijk iets anders: nachtelijke jobs, back-ups, data-imports |
| Het is traag sinds de nieuwe versie | Een wijziging in die versie, en die vindt u het snelst |
| Alles is traag, altijd, voor iedereen | Pas nu is het tijd om naar de server en het netwerk te kijken |
Hoe traagheid wordt opgelost: meten, niet gokken
De duurste fout is repareren wat iemand denkt dat het probleem is. De juiste volgorde is altijd dezelfde:
- MetenWaar de tijd precies heen gaat
- OorzaakDe drie grootste boosdoeners
- OplossenEerst wat het meest pijn doet
- ControlerenCijfers voor en na
- Meten. Tools die al bestaan voor .NET-applicaties en SQL Server laten precies zien welk scherm traag is, hoeveel queries het naar de database stuurt en hoe lang elke query duurt. Daarna wordt er niet meer gegokt.
- Oorzaak. Meestal blijkt dat twee of drie dingen het grootste deel van het probleem veroorzaken. Die worden eerst opgelost.
- Oplossen. Begin met wat gebruikers het meest voelen: een scherm dat iedereen elke dag opent, is belangrijker dan een rapport dat één keer per maand draait.
- Controleren. Dezelfde meting voor en na. Niet “het voelt sneller”, maar “dit scherm opende in 8 seconden en nu in één”.
Zulke verbeteringen zijn vaak een kwestie van dagen of weken, niet van maanden, en vragen niet om het herschrijven van de applicatie. Eenmaal gedaan, worden ze niet elke maand gefactureerd zoals een zwaardere server.
Wanneer u toch een zwaardere server nodig hebt
Soms wel. Als de meting laat zien dat de applicatie verstandig is geschreven en de server voortdurend op zijn limiet zit omdat er steeds meer gebruikers en werk zijn, dan is een zwaardere server de juiste beslissing. Het verschil is dat u die beslissing neemt op basis van cijfers, en niet omdat het het snelste antwoord is.
Hoe wij werken
ProCoding is een .NET-studio uit Split, Kroatië. Performance is een van de dingen die we het vaakst doen: in .NET-applicaties, ASP.NET Core, Blazor, Entity Framework, SQL Server en Azure.
We beginnen met een meting van uw applicatie, en u krijgt een lijst van oorzaken, gerangschikt naar hoeveel pijn ze doen. Daarna lossen wij ze op, of doet uw team dat, wat u het beste uitkomt. De eerste stap is een gratis gesprek van 30 minuten waarin we de symptomen doorlopen en kijken waar we als eerste zouden meten.