Website-, webapplicatie- en API-performance is alles. Veel factoren dragen bij aan de performance, zoals netwerklatentie, gebruik van prestatieverbeterende praktijken (gebruik compressie), het minimaliseren van serverrequests en de kracht van reagerende servers en hun ondersteunende infrastructuur. Als de prestaties van de server achteruitgaan door belasting of ouderdom, kunt u de signalen in uw rapporten vinden. Dit artikel gaat over de verschillende aanwijzingen in uw Synthetics en Real User Monitoring dat uw servers uw aandacht nodig hebben.
Signalen van problemen met de serverperformance in uw monitoringresultaten
Het is misschien niet helemaal duidelijk wanneer achteruitgang van performance rechtstreeks verband houdt met uw server of servertraffic, maar uw monitoring kan u in de goede richting wijzen. Uptrends’ Website, Webperformance, Webapplicatie en API Monitoring controleren allemaal op performance. U kunt zelfs alerting triggeren met performanceresultaten.
De vraag is: “Hoe weet u wanneer u naar de server moet kijken bij het aanpakken van performanceproblemen?” Het antwoord staat in uw rapportage.
Let op langzame toenamen van website- of API-timings
Opwaartse trends in paginalaadtijden of responstijden kunnen hun oorsprong hebben in een toegenomen serverbelasting of -achteruitgang. Het bekijken van de performance over langere perioden kan een langzame progressieve achteruitgang van de paginaperformance of API-responses laten zien die u waarschijnlijk kunt toeschrijven aan serverproblemen.
Problemen door configuratie, codering en inhoud hebben de neiging om plotselinge toenamen van laad- en responstijden te veroorzaken. U moet een stapje terug doen voor het brede perspectief om vertragingen te ontdekken als gevolg van serverbelasting of verouderde servers. In de onderstaande grafiek ziet u een toename gedurende een rapportageperiode van zes maanden voor een webperformance-controleregel (Full Page Check).
In de onderstaande afbeelding ziet u twee watervalgrafieken met een tussenpoos van enkele maanden. U kunt in de onderste grafiek zien dat de wachttijd voor de initiële request meer dan acht seconden is. Als u de controleregel-logs zou doorzoeken, zou u af en toe een performancetest van webpagina’s zien met buitensporige totale laadtijden. Maar na verloop van tijd neemt de frequentie van die langzame laadtijden toe. Als u naar de watervalgrafieken kijkt, kunt u zien dat de wachttijd voor de initiële request is toegenomen van minder dan één seconde tot meer dan acht seconden voor sommige requests. Benchmark de performance van uw website met onze gratis Website Speed Test tool.
Gebruik Gelijktijdige Monitoring om specifieke probleemservers te lokaliseren
Snelle servers kunnen de langzamere servers verschuilen in uw performance monitoring omdat de data aan u worden gepresenteerd op basis van gemiddelden. Dat betekent dat niet al uw bezoekers de hoogwaardige gebruikerservaring krijgen die u wilt bieden.
In het huidige gedistribueerde web leidt u gebruikers naar specifieke servers op basis van hun locatie. Als u zich bijvoorbeeld in Noord-Amerika bevindt, hebt u dit artikel waarschijnlijk bekeken via onze servers in New York, en als u zich in Europa bevindt, is dit waarschijnlijk via de Amsterdamse servers gegaan. Als een van die servers zwaarder wordt belast dan verwacht, is het mogelijk dat de performanceafname niet zichtbaar is in standaardmonitoring totdat de gemiddelden van het hele systeem erdoor omlaag gaan.
Standaard snelheidstests voor websites controleren elke vijf minuten de performance vanaf één locatie. Als u alle 223 wereldwijde controlestationlocaties van Uptrends gebruikt, krijgt u van elk controlestation hooguit twee of drie keer per dag resultaten. Met Gelijktijdige Monitoring is het volgen van de performance van regionale servers eenvoudiger.
Gelijktijdige Monitoring controleert elke vijf minuten vanaf elk controlestation
Als u Gelijktijdige Monitoring gebruikt, geeft u aan welke controlestations de controleregel gebruikt, en in plaats van vanaf één locatie uit uw selectie te controleren, controleert Uptrends ze allemaal tegelijk. Dat betekent dat u een constante aanvoer van performancedata (en beschikbaarheidsdata) krijgt die invloed hebben op de gebruikers in elk controlestationgebied.
Als u siteperformance over een langere periode bekijkt met Gelijktijdige Monitoring, kunt u vertragingen identificeren die niet toe te schrijven zijn aan netwerklatentie. In de onderstaande grafiek kunt u zien dat hoewel de latentie hoger is voor Australië en Korea, de performance stabiel is. Een langere rapportageperiode zou echter subtielere veranderingen in de responstijden van de server vastleggen.
Performancevermindering door serverproblemen met gebruikmaking van Real User Monitoring
Real User Monitoring of RUM houdt de performance voor uw gebruikers bij wanneer ze een door RUM gemonitorde pagina downloaden. RUM houdt de performance bij op basis van de locatie, het apparaat, het besturingssysteem en de browser van de gebruiker. RUM houdt het volgende bij
- Laadtijd
- Tijd tot eerste byte
- Tijd tot pagina-gereed
- Netwerk
- Duur redirect
- DNS-duur
- Duur verbinding
- Backend
- Verzendduur
- Ontvangstduur
- Frontend
- DOM-duur
- Renderduur
- Downloadtijd
Als u data sorteert op basis van locatie en de duur van de backend afzet tegen paginaweergaven, kunt u hieronder zien dat paginaweergaven van invloed zijn op de performance van deze site.
Uw serverperformance in de gaten houden met Infra
Als u toegang hebt tot uw servers, kunt u ook Infra in beeld brengen. Infra kan uw servers rechtstreeks in de gaten houden. Infra biedt serverdiagnostiek die u naar de oorzaak van het probleem kan leiden, zoals CPU-belasting of RAM-gebruik.
Naast uptime zijn er verschillende serverstatistieken die u moet volgen:
- Gelijktijdige gebruikers: het aantal gebruikers op een systeem op een bepaald moment.
- Request per seconde (RPS): aangezien het gebruikersgedrag varieert, is RPS een betere indicator voor serverbelasting.
- Error rates: hoge serverbelasting betekent een grotere kans dat gebruikers errors krijgen.
- Thread counts: hoge thread counts (items die moeten worden verwerkt) kunnen leiden tot hogere error rates omdat de server stopt met het verwerken van wachtende requests om de huidige requestbelasting te managen. Als de wachttijd voor nieuwe requests te lang duurt, krijgt de gebruiker een time-outfout.
- CPU-, geheugen- en schijfgebruik: net als bij iedere computer gaat de performance achteruit als er een tekort is aan CPU, RAM of schijfruimte, als de server niet helemaal uitvalt. Door deze cijfers in de gaten te houden, weet u wanneer uw systeem upgrades of reparaties nodig heeft of dat u meer servers moet toevoegen om de belasting te verwerken.
- Gemiddelde responstijd (ART) en piekresponstijden (PRT): De gemiddelde responstijd is de totale tijd die nodig was voor alle requests gedeeld door het aantal requests. Lage ART kan betekenen dat u het goed doet, maar het volgen van de PRT kan erop wijzen dat u problemen hebt met sommige requests die u moet onderzoeken.
Kernpunten
- Er zijn veel verschillende indicatoren voor problemen met de laadcapaciteit van de server.
- Website Performance Monitoring alleen kan problemen met de laadcapaciteit niet gemakkelijk vangen als er meerdere servers in de mix zitten.
- Het gebruik van Gelijktijdige Monitoring om specifieke servicelocaties te controleren, kan een duidelijker beeld geven van de serverperformance in een regio.
- Door RUM data te filteren op basis van locatie, kunt u backendperformancerapporten krijgen voor specifieke landen en staten.
- Infra agents op uw servers kunnen performance- en uptime-informatie rechtstreeks aan u rapporteren, en binnenkort zullen onze ontwikkelaars Infra-data voor u beschikbaar hebben binnen uw Uptrends-account. Blijf op de hoogte!
