Natuurlijk! Hier is een gedetailleerd load testing plan voor jouw WebSocket-implementatie van de realtime chat applicatie, gericht op het meten van maximale belasting en fouttolerantie met behulp van Artillery. --- **1. Doelstellingen van de test** - Bepalen van de maximale hoeveelheid gelijktijdige WebSocket-verbindingen die de applicatie aankan zonder kritieke prestatieproblemen. - Meten van latency (reactietijd) onder verschillende belastingen. - Evalueren van fouttolerantie en herstelvermogen bij toenemende belasting of netwerkproblemen. **2. Pre-test voorbereiding** - Zorg dat je een stabiele testomgeving hebt, los van productie. - Zorg dat logging en monitoring tools (zoals Grafana, Prometheus, of built-in Artillery metrics) actief zijn. - Definieer duidelijke succescriteria, bijvoorbeeld: - Maximaal 200ms latency onder piekbelasting - 99% van berichten succesvol afgeleverd - Geen crashes of vastlopen van de server --- **3. Testscenario's** **A. Baseline test** - Doel: Controleer of de WebSocket-verbindingen stabiel zijn bij lage belasting. - Opzet: - 10 gelijktijdige verbindingen - Stuur periodiek (bijvoorbeeld elke 5 seconden) een bericht - Meet latency en foutpercentages **B. Graduele belastingstest** - Doel: Identificeer de maximale belasting en de breakpoints. - Opzet: - Start met 20 verbindingen en verhoog stapsgewijs met 10 tot 150 of 200 verbindingen - Bij elke stap: - Houd de verbindingen 1-2 minuten in stand - Meet latency, foutpercentages en serverbelasting (CPU, RAM, netwerk) - Observeer bij welk punt de prestaties verslechteren (bijv. latency > 200ms, foutpercentages toenemen) **C. Sustained stress test** - Doel: Test de stabiliteit onder langdurige belasting. - Opzet: - Houd 100-150 gelijktijdige verbindingen gedurende minimaal 30 minuten - Stuur continue berichten (bijvoorbeeld elke seconde) - Meet latency, foutpercentages en resourcegebruik **D. Fouttolerantietest / Network degradatie** - Doel: Onderzoek hoe de applicatie reageert op netwerkproblemen. - Opzet: - Simuleer packetverlies, vertragingen of verbroken verbindingen (via tools zoals tc op Linux of proxy instellingen) - Observeer hersteltijd en foutafhandeling --- **4. Meetmethoden en KPI’s** - **Latency**: - Meet de round-trip time (RTT) voor berichten - Gemiddelde, mediane en 95e percentiel latencies - **Foutpercentages**: - Percentage berichten dat niet succesvol worden afgeleverd of niet worden ontvangen binnen een bepaalde tijd - **Verbindingstabiliteit**: - Aantal verbroken of onderbroken verbindingen - **Resourcegebruik**: - Server CPU, geheugen en netwerkgebruik tijdens de test - **Herstelvermogen**: - Tijd om verbindingen te herstellen na netwerkproblemen --- **5. Artillery configuratie en scripts** Gebruik een Artillery YAML-configuratie met WebSocket ondersteuning: ```yaml config: target: "wss://jouwdomein.nl/chat" phases: - duration: 300 arrivalRate: 10 name: "Lage belasting" payload: path: "messages.json" fields: message: "Testbericht" scenarios: - engine: "ws" flow: - send: text: "{{ message }}" - think: 1 - think: 5 # Voor periodieke berichten ``` Voor meer geavanceerde tests, zoals het verhogen van de verbindingen, kun je meerdere fases toevoegen: ```yaml phases: - duration: 120 arrivalRate: 10 - duration: 120 arrivalRate: 20 - duration: 120 arrivalRate: 50 - duration: 120 arrivalRate: 100 ``` **Scripts voor fouttolerantie:** Gebruik `beforeRequest` en `afterResponse` hooks om foutpercentages en latency te meten, en log deze data. --- **6. Aanbevelingen voor tools en scripts** - **Artillery**: Voor WebSocket load testing, scripting en rapportages. - **Monitoring tools**: Prometheus, Grafana voor resource monitoring. - **Network simulatie**: tc (Linux), Clumsy (Windows) voor netwerkconditie simulatie. - **Data logging**: Verzamel en analyseer logs, bijvoorbeeld met Elasticsearch of een lokale database. --- **7. Rapportage en analyse** - Verzamel alle testgegevens en visualiseer ze in grafieken. - Identificeer knelpunten en bepaal de maximale belasting. - Documenteer de fouttolerantie en herstelgedrag. --- **8. Aanbevelingen voor verdere optimalisatie** - Optimaliseer WebSocket-server configuraties (bijv. maximum gelijktijdige verbindingen, buffer sizes). - Overweeg load balancing en horizontale schaalbaarheid bij hogere belasting. - Implementeer foutafhandelingsmechanismen voor netwerkproblemen. --- Met dit plan kun je systematisch de prestaties en stabiliteit van jouw WebSocket-verbindingen onder verschillende belasting- en foutcondities evalueren.

Absoluut. Hier is een gedetailleerd load testing plan opgesteld in het Nederlands, specifiek afgestemd op jouw realtime chat applicatie, gebruikersaantal en tooling (Artillery). --- ### **Load Test Plan: Realtime Chat Applicatie met WebSockets** **1. Testdoelstellingen** * **Maximale Belasting Bepalen:** Identificeren bij welk aantal gelijktijdige verbindingen de responslatency van berichten boven de 1000 ms uitkomt of de foutratio (>1%) significant wordt. * **Fouttolerantie Meten:** Verifiëren of het systeem netjes omgaat met een plotselinge piek in verbindingen en abrupte verbindingsverbrekingen, zonder andere kritieke services te beïnvloeden. * **Stabiliteit Onder Belasting:** Aantonen dat de applicatie gedurende een langere periode (bv. 15-30 minuten) op een hoge belasting (bv. 80-90 gebruikers) stabiel blijft zonder geheugenlekken of performance degradation. **2. Testomgeving** * **Doelomgeving:** De test dient zo veel mogelijk uitgevoerd te worden in een omgeving die identiek is aan de productieomgeving (zelfde hardware, netwerkinfrastructuur, load balancers, etc.). Test nooit rechtstreeks op productie. * **Monitoring:** Zorg ervoor dat de volgende metrics gemonitord kunnen worden tijdens de test op de server(s): * CPU- en RAM-gebruik * Netwerk I/O * Aantal actieve WebSocket-verbindingen * Aantal verwerkte berichten per seconde * Eventuele foutlogs (bv. failed handshakes, connection timeouts) **3. Testscenario's** We definiëren drie hoofdscenario's om verschillende belastingsituaties na te bootsen. **Scenario 1: Stapsgewijze Belasting (Ramp-up)** * **Doel:** Het vinden van het breekpunt van de applicatie en het observeren van performance degradation. * **Beschrijving:** Het aantal gebruikers wordt langzaam opgebouwd tot ver boven de geschatte piek van 100 gebruikers. * **Artillery Configuratie (Phases):** ```yaml phases: - duration: 120 # Gedurende 2 minuten arrivalRate: 1 # Start met 1 nieuwe gebruiker per seconde - duration: 300 # Gedurende 5 minuten arrivalRate: 10 # Verhoog naar 10 nieuwe gebruikers per seconde rampTo: 50 # en bouw op tot 50 gelijktijdige gebruikers - duration: 300 # Gedurende 5 minuten arrivalRate: 20 # Verhoog naar 20 nieuwe gebruikers per seconde rampTo: 150 # en bouw op tot 150 gelijktijdige gebruikers (voorbij de piek) ``` **Scenario 2: Plateau van Piekbelasting** * **Doel:** Testen van de stabiliteit en betrouwbaarheid onder een constante hoge belasting. * **Beschrijving:** Breng een groot aantal gebruikers snel online en houd dit volume vast voor een langere periode. * **Artillery Configuratie (Phases):** ```yaml phases: - duration: 180 # Gedurende 3 minuten arrivalRate: 10 # Breng 10 nieuwe gebruikers per seconde online rampTo: 100 # tot we 100 gelijktijdige gebruikers hebben - duration: 900 # Houd 100 gebruikers constant voor 15 minuten arrivalRate: 0 # Geen nieuwe gebruikers maxVusers: 100 # Handhaaf precies 100 gebruikers ``` **Scenario 3: Spiketest en Fouttolerantie** * **Doel:** Simuleren van een extreme, plotselinge piek en testen hoe het systeem verbroken verbindingen afhandelt. * **Beschrijving:** Een zeer snelle, korte piek gevolgd door het abrupt verbreken van alle verbindingen. * **Artillery Configuratie (Phases):** ```yaml phases: - duration: 10 # Binnen 10 seconden... arrivalRate: 50 ... breng 50 nieuwe gebruikers per seconde online (zeer agressief) rampTo: 100 # tot we 100 gebruikers hebben - duration: 30 # Houd dit 30 seconden vast arrivalRate: 0 maxVusers: 100 - duration: 5 # Binnen 5 seconden... arrivalRate: -20 # ... verlaag het aantal gebruikers met 20 per seconde rampTo: 0 # ... tot alle verbindingen gesloten zijn. ``` **4. Gebruikersgedrag (Flow & Functions)** Elke virtuele gebruiker (Vuser) volgt een specifiek script. Hier is een voorbeeld van een Artillery script dat het chatgedrag simuleert. **Script: `chat-simulation.yml`** ```yaml config: target: "ws://jouw-test-server-url:poort" # Vervang door je test server URL phases: # ... (hier komen de phases uit één van de bovenstaande scenario's) plugins: websocket: {} # Zorg dat de Artillery WebSocket plugin actief is ws: # Stel een time-out in voor de WebSocket handshake handshakeTimeout: 5000 # 5 seconden scenarios: - name: "Verbind, chat en verbreek" engine: "ws" flow: # Stap 1: Maak verbinding - think: 1 # Wacht even voor de volgende actie # Stap 2: Verstuur een login/authorisatie bericht (indien van toepassing) - send: op: "auth" token: "{{ $processEnvironment.TEST_USER_TOKEN }}" # Kan gegenereerd worden via een hook # Stap 3: Luister naar een bevestiging - think: 1 # Stap 4: Verstuur een chatbericht. Dit wordt in een loop gedaan. - loop: - send: op: "msg" text: "Hallo, dit is een testbericht van Vuser {{ $uuid }}!" - think: 5 # Wacht gemiddeld 5 seconden tussen berichten - think: 3 # Voeg een willekeurige variatie toe voor realisme count: 10 # Stuur 10 berichten per gebruiker # Stap 5: Verbreek de verbinding netjes - close: ``` **5. Te Meten Metrics & Analyse** Artillery genereert na elke run een uitgebreid rapport. Let op de volgende kernmetrics: * **WebSocket Metrics:** * `websocket.connection.time`: Tijd nodig om de WebSocket-verbinding tot stand te brengen. (< 500ms is goed). * `websocket.messages.sent` & `websocket.messages.received`: Aantal berichten. * `websocket.close.code`: Reden voor sluiten (controleer op abnormale codes). * **Scenario Metrics:** * `vusers.completed`: Totaal aantal succesvolle gebruikerssessies. * `vusers.failed`: Totaal aantal mislukte sessies. **Let hier scherp op!** * `vusers.created`: Totaal aantal gecreëerde virtuele gebruikers. * **Response Times (Latency):** * `http.response_time`: (Ook voor de initiële HTTP handshake) - p95 en p99 percentielen zijn het belangrijkst. Streef naar p95 < 1000ms voor berichten. **6. Aanbevelingen en Best Practices** 1. **Start Klein:** Begin met 10-20 gebruikers om te valideren of je script correct werkt. 2. **Dynamische Data:** Gebruik Artillery's `faker` library of custom hooks om unieke gebruikersnamen, tokens en berichtinhoud te genereren. Dit voorkomt caching-artefacten. 3. **Monitor de Server:** Je Artillery-resultaten zijn slechts één helft van het verhaal. Correlleer de pieken in latency en fouten met de servermetrics (CPU, geheugen, etc.). 4. **Test Herhaalbaarheid:** Voer belangrijke scenario's (zoals het plateau-scenario) meerdere keren uit om consistente resultaten te garanderen. 5. **Let op Limieten:** Controleer of je OS (maximale aantal open bestandsdescriptors) of middleware (bijv. Redis max connections) geen kunstmatige limieten oplegt. 6. **Exit Hooks:** Schrijf een cleanup script om na de test eventuele testdata uit de database te verwijderen. **Opstartcommando:** ```bash # Installeer de WebSocket plugin (eenmalig) npm install -g artillery artillery-plugin-ws # Voer een test uit artillery run --output test-result.json chat-simulation.yml # Genereer een leesbaar rapport na de test artillery report test-result.json ``` Met dit plan kun je systematisch de sterkten en zwakten van je WebSocket-implementatie in kaart brengen. Succes met testen!