Controlelijst- Testen op efficiëntie van prestaties

Is de toepassing getest op prestaties, schaalbaarheid en tolerantie?

Prestatietests helpen systemen correct te onderhouden en defecten op te lossen voordat problemen systeemgebruikers bereiken. Het maakt deel uit van de pijler Prestatie-efficiëntie in Microsoft Azure Well-Architected Framework.

Prestatietests zijn de superset van zowel belastingstests als stresstests. Het belangrijkste doel van prestatietests is het valideren van benchmarkgedrag voor de toepassing.

Met Belasting testen wordt de schaalbaarheid van toepassingen gevalideerd door de belasting van de toepassing snel of geleidelijk te verhogen totdat een drempelwaarde wordt bereikt.

Stresstests is een type negatieve test waarbij verschillende activiteiten worden uitgevoerd om bestaande resources te overbelasten en onderdelen te verwijderen. Met deze tests kunt u inzicht krijgen in de algehele tolerantie en hoe de toepassing op problemen reageert.

Gebruik de volgende controlelijst om uw toepassingsarchitectuur te controleren vanuit het oogpunt van prestatietesten.

Prestaties testen

• Zorg voor een solide prestatietest met gedeelde teamverantwoordelijkheid. Voor het succesvol implementeren van zinvolle prestatietests is een aantal resources vereist. Het is niet slechts één ontwikkelaar of QA-analist die een aantal tests op hun lokale computer uitvoeren. In plaats daarvan hebben prestatietests een testomgeving nodig (ook wel een testomgeving genoemd) die kan worden uitgevoerd tegen zonder dat dit invloed heeft op productieomgevingen en -gegevens. Prestatietests vereisen invoer en toezegging van ontwikkelaars, architecten, databasebeheerders en netwerkbeheerders.

• Capaciteitsplanning. Bij het testen van de prestaties moet het bedrijf schommelingen in de verwachte belasting communiceren. De belasting kan worden beïnvloed door wereldgebeurtenissen, zoals politieke, economische of weerswijzigingen; door marketinginitiatieven, zoals verkoop of promoties; of op seizoensgebonden evenementen, zoals feestdagen. Test variaties van belasting vóór gebeurtenissen, inclusief onverwachte, om ervoor te zorgen dat uw toepassing kan worden geschaald. Bovendien moet u ervoor zorgen dat alle regio's voldoende kunnen worden geschaald om de totale belasting te ondersteunen, mocht één regio uitvallen.

• Identificeer een pad naar het gebruik van bestaande tests of het maken van nieuwe tests. Er zijn verschillende soorten prestatietests: belastingstests, stresstests, API-tests, tests aan clientzijde/browser, en meer. Het is belangrijk dat u de verschillende typen tests, samen met hun voor- en nadelen, begrijpt en verwoordt aan de klant.

• Voer tests uit in alle fasen van de ontwikkelings- en implementatielevenscyclus. Toepassingscode, infrastructuurautomatisering en fouttolerantie moeten allemaal worden getest. Dit kan ervoor zorgen dat de toepassing in elke situatie naar verwachting presteert. U kunt het beste vroeg genoeg testen in de levenscyclus van de toepassing om fouten te ondervangen en op te lossen. Fouten zijn goedkoper om te herstellen wanneer ze vroeg worden storingen en kunnen kostbaar of onmogelijk zijn om later op te lossen. Voor meer informatie verwijzen we u naar Test your application and Azure environment (Uw toepassing en Azure-omgeving testen).

• Vermijd slechte prestaties bij het testen. Twee subsets van prestatietests, belastingstests en stresstests, kunnen respectievelijk de bovengrens en het maximale storingspunt van de capaciteit van de toepassing bepalen. Door deze tests uit te voeren, kunt u de benodigde infrastructuur bepalen om de verwachte workloads te ondersteunen.

• Plan een belastingbuffer om rekening te houden met willekeurige pieken zonder de infrastructuur te overbelasten. Als een normale systeembelasting bijvoorbeeld aanvragen per seconde is, moet de infrastructuur aanvragen van de totale capaciteit 100,000 100,000 ondersteunen 80% (bijvoorbeeld aanvragen per 125,000 seconde). Als u verwacht dat de toepassing aanvragen per seconde blijft ondersteunen en de huidige SKU (Stock Keeping Unit) latentie bij aanvragen per seconde introduceert, moet u waarschijnlijk uw product upgraden naar de volgende hogere 100,000 65,000 SKU. Als er een secundaire regio is, moet u ervoor zorgen dat deze ook de hogere SKU ondersteunt.

• Test de failover in meerdere regio's. Test de hoeveelheid tijd die het zou duren om gebruikers om te leiden naar de gekoppelde regio, zodat de regio niet uitvallen. Normaal gesproken kan een geplande test-failover helpen bepalen hoeveel tijd er nodig is om volledig te schalen ter ondersteuning van de omgeleide belasting.

• Configureer de omgeving op basis van testresultaten om de prestatie-efficiëntie te handhaven. Uitschalen of inschalen om toe- en afname van de belasting te verwerken. U weet bijvoorbeeld dat er tijdens de dag veel verkeer is en dat er in het weekend weinig verkeer is. U kunt de omgeving configureren om uit te schalen voor een toename van de belasting of om in te schalen voor afnames voordat de belasting daadwerkelijk verandert.

Testhulpprogramma's

• Kies testhulpprogramma's op basis van het type prestatietest dat u probeert uit te voeren. Er zijn verschillende hulpprogramma's voor prestatietests beschikbaar voor DevOps. Sommige hulpprogramma's JMeter zoals voeren alleen tests uit op eindpunten en testen HTTP-statussen. Andere hulpprogramma's, zoals K6 en Selenium, kunnen tests uitvoeren die ook de kwaliteit en variaties van gegevens controleren. Hoewel Insights toepassingstoepassing niet noodzakelijkerwijs is ontworpen om de serverbelasting te testen, kan de prestaties van een toepassing in de browser van de gebruiker worden getest.

• Voer prestatieprofilering en belastingstests uit tijdens de ontwikkeling, als onderdeel van testroutines en vóór de definitieve release om ervoor te zorgen dat de toepassing naar eigen vermogen wordt uitgevoerd en geschaald. Deze tests moeten worden uitgevoerd op hetzelfde type hardware als het productieplatform, met dezelfde typen en hoeveelheden gegevens en gebruikersbelasting als bij productie.

• Bepaal of het beter is om geautomatiseerde of handmatige tests te gebruiken. Testen kan geautomatiseerd of handmatig worden uitgevoerd. Het automatiseren van tests is de beste manier om ervoor te zorgen dat ze worden uitgevoerd. Afhankelijk van hoe vaak tests worden uitgevoerd, zijn ze doorgaans beperkt in duur en bereik. Handmatig testen wordt veel minder vaak uitgevoerd.

• Cachegegevens om de prestaties, schaalbaarheid en beschikbaarheid te verbeteren. Hoe meer gegevens u hebt, hoe groter de voordelen van caching worden. Caching werkt gewoonlijk goed voor gegevens die onveranderlijk zijn of niet vaak worden gewijzigd.

• Bepaal hoe u lokale ontwikkeling en testen wilt uitvoeren wanneer bepaalde statische inhoud naar verwachting wordt geleverd vanuit een netwerk voor contentlevering (CDN). U kunt bijvoorbeeld de inhoud vooraf naar het CDN implementeren als onderdeel van uw buildscript. Gebruik in plaats daarvan compilatie-instructies of vlaggen om te bepalen hoe de toepassing de resources laadt. In de foutopsporingsmodus kan de toepassing bijvoorbeeld statische resources van een lokale map laden. In de releasemodus gebruikt de toepassing het CDN.

• Simuleer verschillende workloads in uw toepassing en meet de prestaties van de toepassing voor elke workload. Deze techniek is de beste manier om te achterhalen welke resources u nodig hebt om uw toepassing te hosten. Gebruik prestatie-indicatoren om te beoordelen of uw toepassing werkt zoals verwacht.

Aanbeveling

Een teststrategie definiëren. Voor meer informatie verwijzen we naar Testen.

Volgende stappen