API-belastingtesten met Locust
API-belastingtesten met Locust: inleiding
Je hebt vast al eens in deze situatie gezeten: je schrijft code die iets doet, een endpoint bijvoorbeeld. U test uw eindpunt met Postman of Insomnia en alles werkt prima. U geeft het eindpunt door aan de ontwikkelaar aan de clientzijde, die vervolgens het API en implementeert de applicatie. Maar dan faalt de API wanneer de gebruikers de app gebruiken.
Dit kan een super irritante situatie zijn om in te verkeren, om nog maar te zwijgen van de kosten voor een bedrijf. Daarom voeren softwareontwikkelaars verschillende tests uit op softwaresystemen om ervoor te zorgen dat ze naar verwachting presteren. API's zijn niet anders. Voorafgaand aan de implementatie moet u ten minste prestatietests en beveiligingstests uitvoeren.
Prestatietests kunnen worden gegroepeerd in functionaliteitstests en belastingstests. Functionaliteitstests zijn waar je Postman of Insomnia meestal voor gebruikt. Ze zorgen ervoor dat uw API functioneert zoals u verwacht. Load-tests daarentegen houden zich meer bezig met hoe uw API presteert bij gebruik in de echte wereld en piekbelasting, en daar gaat dit artikel over. Laten we de belastingstests in meer detail bekijken.
Wat is API Load Testing?
API-belastingtesten is een type test dat ontwikkelaars gebruiken om normale en piekbelasting op eindpunten te simuleren. Met dit soort tests kunnen ontwikkelaars de real-world prestaties van een API evalueren voordat deze wordt geïmplementeerd. Het helpt hen de maximale operationele capaciteit van een systeem, eventuele knelpunten en prestatievermindering te identificeren. API-belastingtests worden meestal uitgevoerd door virtuele gebruikers te maken en deze vervolgens te gebruiken om de functionaliteit van de API gelijktijdig uit te testen.
API-belastingtests meten statistieken zoals responstijd, gelijktijdige gebruikers, doorvoersnelheden, resourcegebruiksniveaus, Mean Time Between Failure (MTBF), Mean Time To Failure (MTTF), enzovoort. Al deze statistieken kunnen worden gebruikt om te bepalen hoe goed de API presteert.
Soorten belastingtesten
Er zijn verschillende soorten belastingtesten, elk met zijn eigen use-cases. Laten we er een paar bekijken.
Belasting testen: Dit is de basisvorm van een belastingstest. Het wordt gebruikt om de prestaties van een systeem (in dit geval een API) te evalueren onder normale belasting en verwachte piekbelasting.
Stress testen: Dit wordt gebruikt om de prestaties van een systeem onder zeer zware belasting te evalueren. Het doel van deze test is om te zien of een systeem herstelt na een storing, en hoe lang het duurt om dit te doen. De belasting wordt meestal langzaam opgevoerd totdat deze de mogelijkheden van het systeem overschrijdt.
Spike-testen: Dit lijkt een beetje op stresstesten, behalve dat er plotseling een zware belasting wordt uitgeoefend, in plaats van deze langzaam op te voeren. Dit soort test geeft weer wat er gebeurt als er een plotselinge piek is in uw gemiddelde aantal gebruikers of bezoekers, of als er een DDOS-aanval op uw systeem plaatsvindt.
Doorweek het Testen: Deze test is anders dan de andere hierboven. Het plaatst uw systeem onder 80% (of daaromtrent) van de normale belasting en laat het gedurende een lange periode draaien, zeg 12 tot 14 uur. Dit soort testen bepaalt hoe betrouwbaar een systeem in de loop van de tijd is.
Laad uw API's testen met Locust
Ontwikkelaars hebben toegang tot verschillende opties voor het testen van hun API's. Enkele veelgebruikte tools voor het testen van belastingen zijn Gatling, JMeter en Locust. In dit artikel zullen we ons concentreren op Locust.
Locust is een op python gebaseerde open-source load-testtool die wordt gebruikt door topbedrijven zoals Google, Microsoft en Riot Games om hun API's te testen. In dit artikel laten we zien hoe u een API laadt.
Voor deze zelfstudie maak ik een eenvoudige API met Flask. Je kunt met mij meegaan of gewoon je API maken met Node, of welk framework je ook prettig vindt.
Voorwaarden
Python 3
Installatie & Installatie
Eerst moet u een virtuele omgeving op uw pc opzetten, zodat u uw wereldwijde Python-omgeving niet verknoeit. Voer hiervoor de volgende opdrachten uit. Merk op dat deze opdrachten van toepassing zijn op een Windows-terminal.
$ mkdir-project
$ cd /d pad\naar\project
$ python -m venv venv
$ venv\Scripts\activeren
Eerst hebben we een project map. Vervolgens hebben we onze huidige directory gewijzigd in project. Vervolgens hebben we in die map een virtuele omgeving voor Python gemaakt en geactiveerd.
Nu gaan we verder met installeren Flacon(we zullen het gebruiken om de eindpunten te maken die moeten worden getest op belasting) en Sprinkhaan zelf.
Om Flask te installeren, voer je uit. Zorg dat je in de project waar je een virtuele omgeving hebt gemaakt.
$ pip installatiefles
Voer het programma Locust uit om Locust te installeren
$ pip installeer sprinkhaan
Zodra dat is gebeurd, typt u de volgende opdrachten. Zorg dat je in je project directory wanneer u dit doet.
$ kopiëren nul __init__.py
$ mkdir-app
$ kopiëren nul app\app.py
$ kopieer nul app\__init__.py
Met deze opdracht worden enkele bestanden gemaakt die we zullen gebruiken om onze eindpunten te maken met Flask. Je kunt deze bestanden trouwens ook maken met je bestandsverkenner. Maar wat is daar nou leuk aan? Zodra je dat hebt gedaan, kopieer je de onderstaande code naar app.py
uit kolfimport Flask, jsonify, verzoek
app = Kolf(__naam__)
auto_modellen = [
{ 'merk': 'Tesla', 'model': 'Model S' }
]
vliegtuig_models = [
{ 'merk': 'Boeing', 'model': '747' }
]
@app.route('/auto's')
def get_cars():
retourneer jsonify(car_models)
@app.route('/vliegtuigen')
def get_planes():
retourneer jsonify(plane_models)
if __name__ == '__main__':
app.run(debug=Waar)
De bovenstaande code bevat een methode krijg_auto's gebruikt om een lijst met automerken en hun modellen te krijgen, en krijg_vliegtuigen gebruikt om een lijst met vliegtuigmerken en hun modellen te krijgen. Om dit eindpunt te kunnen laden, moeten we app.py uitvoeren. Voer hiervoor de onderstaande opdracht uit.
$ python pad\naar\app.py
Als je dat eenmaal hebt uitgevoerd, zou je zoiets als dit moeten zien:
Als u de URL van de terminal kopieert en typt auto's or vliegtuigen na de / zou je de gegevens daar moeten kunnen zien. Ons doel is echter om het eindpunt te testen met sprinkhaan, niet met de browser. Dus laten we dat doen. Voer de volgende opdracht uit in de root van uw project directory.
$ kopiëren nul locust_test.py
Dit creëert een 'locust_test.py' bestand in de root van uw project map. Zodra je dat hebt gedaan, open je het bestand en plak je de onderstaande code. We zullen het binnenkort uitleggen.
import tijd
from sprinkhaan import HttpUser, taak, tussen
klasse UserBehaviour(HttpUser):
wacht_tijd = tussen(5, 10)
@taak
def get_cars(zelf):
zelf.klant.get('/auto's')
@taak
def get_planes(zelf):
zelf.client.get('/planes')
Dit is een basisvoorbeeld van het gebruik van Locust om een API te laden. Eerst maken we een klasse aan Gebruikersgedrag, waaraan elke toepasselijke naam kan worden gegeven, maar moet worden uitgebreid Http-gebruiker. Http-gebruiker is de klasse die zorgt voor het instantiëren van meerdere virtuele gebruikers om de taken uit te voeren die we specificeren in de Gebruikersgedrag klasse.
Een taak wordt gespecificeerd door een methode te decoreren met de @taak decorateur. We hebben ook een functie genaamd tussen() waarmee we een reeks seconden kunnen specificeren waarop moet worden gewacht voordat de volgende taak wordt uitgevoerd. Je kunt zien dat we daarvoor in onze code een bereik van 5 tot 10 seconden hebben toegewezen.
Zorg ervoor dat u zich nog steeds in uw virtuele omgeving bevindt om de code uit te voeren. Als degene die je hebt gemaakt wordt gebruikt door de server die de API bedient, open dan een nieuwe terminal, verander je directory naar je project directory en activeer de virtuele omgeving die u hebt gemaakt. Het commando voor het activeren van een virtuele omgeving vind je hierboven. Voer nu de onderstaande opdracht in uw terminal in.
$ sprinkhaan -f locust_test.py
Je zou zoiets als dit moeten zien:
De webinterface van locust bevindt zich standaard op http://localhost/8089. Als u de website bezoekt, zou u een interface als deze moeten zien:
Vanuit de interface kunnen we het aantal gebruikers, spawn-snelheid (gebruikers aangemaakt per seconde) en Host specificeren. U kunt het adres van uw host achterhalen door de terminal te controleren waarop de server draait. In ons geval is dat op poort 5000. Als je op klikt Begin te zwermen, je krijgt de onderstaande interface te zien.
Dit toont u verschillende nuttige statistieken, zoals het aantal mislukte verzoeken, de gemiddelde tijd voor een verzoek, de minimale tijd voor een verzoek, verzoeken per seconde, enzovoort. Als u tevreden bent met wat u ziet, kunt u op de stopknop klikken.
Naast Statistieken tabblad, er is een Grafieken tabblad dat meer laat zien informatie in de vorm van een grafiek, zoals de afbeelding hieronder.
Er is een totale verzoeken per seconde grafiek, reactietijd grafiek, en aantal gebruikers grafiek, allemaal uitgezet tegen de tijd. Aan de hand van de grafieken kunt u bepalen hoeveel gebruikers acceptabel zijn voor een vaste responstijd, of u kunt uw grafieken observeren voor een constante responstijd ondanks een toenemend aantal gebruikers, en andere inzichten zoals dat. Mocht je deze willen delen stats met iemand anders kunt u een rapport downloaden van de Download Data Tab.
Concluderen...
Het testen van uw API is een cruciale activiteit in uw ontwikkelingsproces, dus zorg ervoor dat het is opgenomen in uw ontwerpcyclus. Overigens kun je ook andere soorten belastingstests uitvoeren door de waarden voor het aantal gebruikers en de spawn-snelheid te variëren.
Als u een spike-test wilt doen, geeft u een grote waarde op (bijvoorbeeld 2000) voor het aantal gebruikers en vervolgens een even grote waarde voor uw spawn-snelheid (bijvoorbeeld 500). Dit betekent dat u in 4 seconden alle 2000 gebruikers heeft gemaakt en toegang heeft tot uw eindpunten. Een stresstest zal vergelijkbaar zijn, maar met een veel lagere waarde voor de spawnsnelheid. Bekijk de Locust om erachter te komen wat je allemaal kunt doen documentatie.
