Vijf manieren om je webapplicatie sneller te maken

Edwin Klesman

Als je gedurende de afgelopen tien jaar een maatwerk webapplicatie hebt aangeschaft of je hebt een Minimum Viable Product (MVP) versie van je product gelanceerd, herken je wellicht de volgende situatie;

Het gebruik van de webapplicatie is - net als de hoeveelheid data - is aanzienlijk toegenomen, en de applicatie lijkt langzamer te zijn geworden en reageert minder vlot.

In dit artikel laat ik je vijf manieren zien waarmee je een bestaande webapplicatie sneller kunt maken, en licht elke manier toe. Zo krijg je inzicht in de aspecten waardoor een applicatie traag kan zijn geworden, en draag ik je de mogelijke de oplossing aan waarmee je de performance van de applicatie positief kunt beïnvloeden.

 

 

 

De wet van de remmende voorsprong

Dat een applicatie op den duur trager wordt, is alleen maar logisch. Zelfs als deze hetzelfde blijft performen, wordt je applicatie op den duur als "trager" ervaren omdat andere applicaties gebouwd worden met snellere frameworks, op snellere platformen en met vernieuwde inzichten zoals die van de toegepaste software architectuur.

En dat is logisch, want al is je applicatie destijds gebouwd met behulp van state of the art technologie, deze verouderd na een aantal jaren. Dit wil niet zeggen dat je applicatie volledig herbouwd moet worden, maar wijzigingen doorvoeren ten behoeve van de performance en onderhoudbaarheid zijn geen onnodige handelingen.

Als je een applicatie hebt laten maken die je als product in de markt hebt gezet, is de toename van het aantal betalende gebruikers hopelijk de reden dat je applicatie trager begint te worden. En dat is ook niet volledig te voorkomen.

Je kunt performance testen en stress testen uitvoeren, maar daarmee test je uiteindelijk alleen bepaalde uitgangspunten voor het gebruik van je applicatie en de bijbehorende functionaliteiten.

Alleen door het daadwerkelijk in gebruik observeren van een webapplicatie (zeker bij grotere, complexer applicaties) merk je welke functionaliteiten het meest gebruikt worden, waar de meeste data uit voortkomt en waar de bottlenecks zitten die de gebruikerservaring verminderen.

De voorsprong die je applicatie had (door de gebruikte technologieën of de snelle time-to-market door alleen de hoognodige features te laten bouwen) wordt kleiner, en er is werk aan de winkel om je applicatie weer te laten performen.

Hoe eerder je dit punt herkent, hoe beter je je applicatie kunt bijsturen waar nodig zodat je het voordeel blijft behouden.

In dit stuk laat ik je vijf manieren zien om je webapplicatie weer te laten performen.

 

Vijf Manieren Om je Webapplicatie Te Versnellen

De wijzen waarop je een webapplicatie weer kunt laten performen zijn allemaal mogelijk van toepassing en geschikt voor jouw applicatie. 

Houdt er wel rekening mee dat iedere (maatwerk) applicatie anders is, dus sommige manieren zullen effectiever zijn dan andere en een andere mate van inspanning en kosten met zich meedragen.

1 Opschalen Infrastructuur

Deze manier zal niet heel onbekend zijn, maar kan desondanks interessant zijn.

Door het verplaatsen van je applicatie naar een betere server (met meer geheugen, snellere processor, etc.) kun je je webapplicatie een performance boost geven.

 

Verticaal opschalen

Wat zeker interessant is in dit tijdperk van werken in de Cloud, is dat wanneer je je applicatie van een eigen server naar de cloud verhuist, je de server kunt opschalen naar mate dat het gebruik toeneemt.

Wordt je applicatie toenemend gebruikt of zie je bepaalde perioden waarin deze extra capaciteit van je server vraagt? Dan kun je de virtuele server meer geheugen, harddisk en een zwaardere CPU toekennen. Dat noemt men verticaal opschalen

Horizontaal opschalen

Als je applicatie al zo gebouwd is dat deze op meerdere servers kan draaien, en het gebruik verdeeld kan worden - middels load balancing - over meerdere servers, dan kun je ook horizontaal opschalen; je voegt dan meer servers toe waardoor er meer rekenkracht beschikbaar komt om aan de gebruikersvraag te voldoen.

Beiden zijn manieren om je infrastructuur op te schalen zodat je de software zelf niet of nauwelijks hoeft aan te passen. 

Let wel op dat wanneer je applicatie over meerdere systemen verdeeld is, je bepaald welke onderdelen een upgrade nodig hebben. Zo kan het opschalen van de server waarop je databases draaien al voldoende impact hebben om je webapplicatie weer vlot te laten werken. 

De meeste inspanningen en kosten gaan bij het opschalen van de infrastructuur meestal in het configureren en de (virtuele) infrastructuur uitbreidingen zelf zitten.

2 Een nieuwere framework versie

Door het gebruik van frameworks kunnen applicaties sneller, volgens best practices, en met platform specifieke voordelen geïmplementeerd worden.

Denk hierbij bijvoorbeeld aan het .Net framework van Microsoft, waarmee vele applicaties gemaakt zijn die op Windows draaien.

 

 

Door een nieuwere versie van zo'n framework te gebruiken dan die waar je applicatie momenteel op stoelt, kun je vaak ook gebruik maken van snellere functies of logica, en van de optimalisaties die het framework heeft doorgevoerd voor een beter geheugen- of processor gebruik.

Hierbij kun je bijvoorbeeld denken het verbeterde geheugen beheer van een nieuwere versie van het framework, waardoor de applicatie minder geheugen nodig heeft en beter performt.

Een ander voorbeeld is een geoptimaliseerd lijst component dat veel in je applicatie wordt gebruikt, waarvan de versie in het nieuwere framework dat minder geheugenkracht en performance vraagt van de browser van je eindgebruikers.

Opgelet: een nieuwe framework versie heeft minder impact dan een ander framework toepassen. Een framework is sterk geïntegreerd met de applicatie logica en code en het wijzigen van het framework betekent vaak herbouw van de applicatie

Afhankelijk van hoe het framework is gebruikt en hoe je applicatie is opgezet, gaat het werk bij deze aanpak zitten in het analyseren van je software, het juist doorvoeren van de framework upgrade en het bijwerken/optimaliseren van je applicatie code waar nodig.

Een webapplicatie is slechts zo snel als het langzaamste onderdeel in diens keten

3 Asynchrone Communicatie

Welk scenario lijkt je prettiger:

A) Als gebruiker verstuur je informatie, en na een tijdje krijg je het antwoord, waarna kun je weer verder met het gebruik van de applicatie
B) Je vult wat gegevens in en drukt op "berekenen", vervolgens vul je nog wat andere gegevens in en ontvangt ondertussen het resultaat 

De meeste mensen zeggen op dit punt "B". Je wilt graag kunnen doorwerken ook als je niet meteen alle gegevens binnen krijgt. Deze vorm van asynchroon werken bespaart je tijd en zorgt ervoor dat je applicatie fijner en sneller werkt.

 

 

Alle recente frameworks hebben dit al ingebouwd, en dus vaak ook de applicaties die daarop gebouwd zijn. 
Maar applicaties van 10 jaar geleden werken mogelijk nog met synchrone communicatie.

Manier 3 om je applicatie sneller te maken is dan ook om te checken  of het framework waarop dit gebouwd is asynchrone communicatie ondersteund. Als dat zo is, kun je (laten) bepalen welke functionaliteiten zich eigenen voor asynchrone afhandeling en zo bepalen waar je hiermee de meeste tijdswinst voor de meeste gebruikers behaalt.

Mocht de gebruikte framework versie dit nog niet ondersteunen, dan kun je deze manier goed combineren met manier 2.
De meeste inspanningen gaan zitten in de analyse en de wijzigingen van synchroon naar asynchrone communicatie in de software. 

Een webapplicatie is slechts zo snel als het langzaamste onderdeel in diens keten. Waar we in punt 1 de infrastructuur en punt 2 en 3 de software aanspraken, komt de database in manier 4.

4 Database Optimalisatie

De hoeveelheid data neemt vaak toe, samen met de toename van het aantal gebruikers. Ook kan het zijn dat nog veel gegevens worden opgeslagen maar deze niet wordt opgeschoond. Beide situaties kunnen ervoor zorgen dat de database server meer moeite moet doen om  de benodigde gegevens te verwerken.

 

Toename gegevens

Door de database goed te analyseren kun je vaak al snel zien of de opzet van de database mogelijk tot performance issues leidt; zo kan het zijn dat er veel dubbele data in zit omdat het gegevensmodel niet genormaliseerd is (veel records bevatten dan dezelfde informatie). 

Een ander issue kan zijn dat er geen of onjuiste database indexering is toegepast op de 

tabellen. Database indexering kan vergeleken worden met de index van een dik boek; het helpt de database om sneller naar de juiste pagina te gaan om de betreffende informatie uit te lezen. 

Gelukkig zijn er tools waarmee de database kan worden geanalyseerd, die vervolgens aangeeft welke indexering toegepast moet worden om de meeste snelheidswinst te behalen.

Je maakt de database als het ware robuuster om - zelfs met meer data - toch snel de juiste gegevens bij elkaar te kunnen rapen.

Opschonen gegevens

Een andere manier om de database te optimaliseren, is om na te gaan welke gegevens mogen worden verwijderd. 

Dat klinkt enger dan het is: vaak zijn er zaken zoals log gegevens die niet worden opgeschoond, en niet meer relevant zijn. 

Of worden financiële gegevens veel langer worden bewaard dan nodig voor de administratie of voor inzichten van de applicatie.

Door verouderde data bijvoorbeeld in een back-up te zetten en deze te verwijderen uit de actieve database van de webapplicatie, kun je de database weer sneller laten werken. Door een zogenaamd data policy op te stellen kun je vastleggen wat voor hoe lang wordt bewaard en dit laten toepassen op de database.

SQL queries verbeteren

Om een webapplicatie met de gegevens uit een database te laten praten is er links- of rechtsom iets nodig waarmee de logica de juiste gegevens kan uitlezen uit en wegschrijven naar de database.

Dit wordt vaak in een soort selectie taal vastgelegd, wat ontwikkelaars kennen als de query syntax. 

Er zijn database platformen die deze "SQL query syntax" gebruiken om gegevens over meerdere tabellen te kunnen opzoeken middels verwijzingen in de gegevens (de zogenaamde relationele databases). 

Denk hierbij aan Microsoft SQL, MySql, PostgreSQL, etc.

De queries die hierbij gebruikt worden, zijn vaak in (een laag van) de applicatiecode gecodeerd. Door het analyseren van de queries die tijdens het gebruik van de applicatie worden uitgevoerd, kunnen de uitschieters - zoals de traagste of langstlopende queries - worden bepaald.

Vervolgens kan worden gekeken hoe de betreffende queries sneller gemaakt kunnen worden.

5 Gegevens Caching

Niet alle gegevens in een webapplicatie moeten bij ieder bezoek aan een scherm of gebruik van een onderdeel telkens volledig opnieuw uit de database worden opgehaald.

Als je goed kijkt naar het soort gegevens dat in een applicatie wordt gebruikt, zul je vaak zien dat er gegevens zijn die vaak - mogelijk zelfs continu - bijgewerkt worden. Dit zijn de zogenaamde vluchtige gegevens (de zogenaamde volatile data). 

Maar vaak zie je ook een hoop gegevens die periodiek worden bijgewerkt of soms zelf alleen na aanpassingen van de applicatielogica worden uitgebreid.

Je kunt een webapplicatie vaak vele malen sneller maken door deze minder vluchtige gegevens tijdelijk bijvoorbeeld in het geheugen op te slaan, zodat ze niet telkens uit de database bij elkaar gezocht moeten worden.

Dat principe noemen we gegevens caching: gegevens die niet vaak wijzigen sla je tijdelijk op in een sneller medium dan een SQL database, waardoor de gegevens vrijwel direct worden teruggegeven.

 

Caching kan tot enorme snelheidsverbeteringen leiden, wat gebruikers altijd zullen waarderen.

 

En wat nu als er wel iets wijzigt in de gecachte data? Door aan de ene kant goed te kijken naar welke gegevens minder vaak wijzigen, en aan de andere kant te achterhalen hoe en wanneer deze wél wijzigen, kun je de caching zo toepassen dat deze geleegd wordt zodra gerelateerde gegevens zijn bijgewerkt. 

Als je deze manier toepast, gaat het meeste werk zitten in het bepalen van waar je de caching gaat toepassen, hoe lang de gegevens gecached moet worden en bepalen wanneer een cache niet meer actueel is.

 

Tot slot

Als het goed is heb je na het lezen van dit artikel meer inzicht gekregen op de verschillende aspecten waarmee je je webapplicatie sneller zou kunnen (laten) maken.

Bij ieder van de vijf manieren om je webapplicatie sneller te maken heb ik aangegeven welk probleem je oplost, hoe het invloed heeft op je applicatie en waar de inspanningen in gaan zitten.

Afhankelijk van hoe je webapplicatie is gebouwd, je budget en doelstellingen kun je één of meer van de vijf manieren combineren. 

Het is belangrijk om eerst helder te hebben welke zaken voor jouw applicatie gelden. Kijk daarom eerst naar de pilaren waar jouw applicatie op is gebouwd: 

• de gebruikte infrastructuur

• het framework en diens versie waarmee je webapplicatie is gebouwd

• de opzet van je database en de hoeveelheid gegevens

Bepaal vervolgens welke manieren met de minste inspanning en kosten voor jouw applicatie de meeste snelheidswinst met zich meebrengen.

Als je bovenstaande stappen hebt doorlopen heb je de basis gelegd voor de weg naar een verbeterde gebruikerservaring van je webapplicatie en is deze weer klaar voor de volgende ronde nieuwe gebruikers van je applicatie.