Lastteststrategien für Webanwendungen: Finden Sie Bruchstellen, bevor Benutzer es tun

80 % der Leistungsprobleme werden von Endbenutzern entdeckt, nicht durch Tests. Lasttests kehren dieses Verhältnis um, indem sie reale Verkehrsmuster für Ihre Anwendung simulieren, bevor Benutzer auf Probleme stoßen. Der Unterschied zwischen einer Website, die den Black Friday-Verkehr verarbeitet, und einer Website, die abstürzt, besteht fast immer darin, ob jemand zuerst einen Auslastungstest durchgeführt hat.

Dieser Leitfaden behandelt die Auslastungstestmethodik, die Toolauswahl, das Testdesign und die Ergebnisinterpretation für Webanwendungen, E-Commerce-Plattformen und ERP-Systeme.

Wichtige Erkenntnisse

• Lasttests sollten realistisches Benutzerverhalten simulieren und nicht nur einen einzelnen Endpunkt belasten
• Legen Sie vor der Optimierung Leistungsgrundwerte fest – Sie können nicht verbessern, was Sie nicht gemessen haben
• Lasttests in einer produktionsähnlichen Umgebung durchführen; Die Staging-Ergebnisse spiegeln möglicherweise nicht das Produktionsverhalten wider – Automatisieren Sie Lasttests in CI/CD, um Leistungsrückgänge vor der Bereitstellung zu erkennen

---

Arten von Lasttests

---

Lasttest mit k6

Grundlegender Lasttest

// k6/load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp up to 50 users
    { duration: '5m', target: 50 },   // Stay at 50 users
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    http_reqs: ['rate>100'],
  },
};

export default function () {
  // Simulate realistic user behavior
  const homeResponse = http.get('https://example.com/');
  check(homeResponse, {
    'homepage status is 200': (r) => r.status === 200,
    'homepage loads in under 1s': (r) => r.timings.duration < 1000,
  });
  sleep(Math.random() * 3 + 1); // 1-4 seconds think time

  const productsResponse = http.get('https://example.com/api/v1/products');
  check(productsResponse, {
    'products API is 200': (r) => r.status === 200,
    'products API under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(Math.random() * 2 + 1);
}

E-Commerce-User-Journey-Test

// k6/ecommerce-journey.js
import http from 'k6/http';
import { check, group, sleep } from 'k6';

export const options = {
  scenarios: {
    browsing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '10m', target: 200 },
        { duration: '5m', target: 0 },
      ],
      exec: 'browsingScenario',
    },
    purchasing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 20 },
        { duration: '10m', target: 20 },
        { duration: '5m', target: 0 },
      ],
      exec: 'purchaseScenario',
    },
  },
  thresholds: {
    'http_req_duration{scenario:browsing}': ['p(95)<800'],
    'http_req_duration{scenario:purchasing}': ['p(95)<2000'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browsingScenario() {
  group('Browse Products', () => {
    http.get('https://store.example.com/');
    sleep(2);
    http.get('https://store.example.com/products');
    sleep(3);
    http.get('https://store.example.com/products/sample-product');
    sleep(2);
  });
}

export function purchaseScenario() {
  group('Purchase Flow', () => {
    // Browse
    http.get('https://store.example.com/products/sample-product');
    sleep(1);

    // Add to cart
    http.post('https://store.example.com/api/cart', JSON.stringify({
      productId: 'prod_123',
      quantity: 1,
    }), { headers: { 'Content-Type': 'application/json' } });
    sleep(2);

    // Checkout
    http.get('https://store.example.com/cart');
    sleep(3);

    // Place order (simulated)
    const orderResponse = http.post('https://store.example.com/api/checkout/validate', JSON.stringify({
      email: `test-${__VU}@example.com`,
    }), { headers: { 'Content-Type': 'application/json' } });

    check(orderResponse, {
      'checkout validates': (r) => r.status === 200 || r.status === 201,
    });
    sleep(1);
  });
}

Stresstest (Den Bruchpunkt finden)

// k6/stress-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 500 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 1000 },
    { duration: '5m', target: 1000 },
    { duration: '5m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

---

Ergebnisse interpretieren

Schlüsselmetriken

Häufige Engpassmuster

CPU-bedingter Engpass: Die Reaktionszeit steigt linear mit der Auslastung. P95 und P99 weichen langsam voneinander ab.

• Fix: Hot-Code-Pfade optimieren, CPU-Kapazität hinzufügen oder horizontal skalieren

Datenbankengpass: Die Reaktionszeit steigt bei einem bestimmten Lastschwellenwert exponentiell an. Erschöpfung des Verbindungspools.

• Fix: Abfrageoptimierung, Verbindungspooling, Lesereplikate (siehe Anleitung zur Datenbankskalierung)

Speicherengpass: Allmähliche Verschlechterung im Laufe der Zeit. GC-Pausen verursachen Latenzspitzen.

• Fix: Speicher erhöhen, Speicherlecks beheben, Objektzuordnung optimieren

Netzwerkengpass: Die Reaktionszeit erhöht sich gleichmäßig über alle Endpunkte hinweg. Bandbreitensättigung. – Fix: CDN für statische Assets, Komprimierung, Reduzierung der Nutzlastgrößen

---

Leistungsbasislinien

Festlegung einer Baseline

Dokumentieren Sie vor der Optimierung Ihre aktuelle Leistung:

# Run baseline test
k6 run --out json=baseline-results.json k6/load-test.js

# Compare after optimization
k6 run --out json=optimized-results.json k6/load-test.js

Leistungsbudget

Definieren Sie eine akzeptable Leistung für jeden Endpunkt:

---

CI/CD-Integration

Automatisierte Leistungsregressionstests

# .github/workflows/performance.yml
name: Performance Test
on:
  push:
    branches: [main]

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run k6 load test
        uses: grafana/[email protected]
        with:
          filename: k6/load-test.js
          flags: --out json=results.json
        env:
          K6_TARGET_URL: ${{ secrets.STAGING_URL }}

      - name: Check thresholds
        run: |
          if grep -q '"thresholds":{".*":"fail"' results.json; then
            echo "Performance thresholds exceeded!"
            exit 1
          fi

---

Checkliste für Auslastungstests

Vor dem Testen

• Umgebung entspricht der Produktion (Instanztypen, Datenbankgröße)
• Testdaten sind repräsentativ (realistische Produktanzahl, Benutzeranzahl)
• Überwachung ist aktiv (Servermetriken während des Tests verfolgen)
• Stakeholder werden benachrichtigt (Belastungstests können Warnungen auslösen)
• CDN und Caching sind wie in der Produktion konfiguriert

Während des Tests

• Server-CPU, Speicher, Festplatten-E/A überwachen
• Überwachen Sie Datenbankverbindungen und Abfragelatenz
• Achten Sie auf einen Anstieg der Fehlerquote
• Auf Ressourcenerschöpfung prüfen (Dateideskriptoren, Verbindungen)
• Beachten Sie die Laststufe, bei der die Leistung nachlässt

Nach dem Testen

• Basisergebnisse dokumentieren
• Identifizieren Sie Engpässe und deren Auslastungsschwellen
• Erstellen Sie Tickets für Leistungsverbesserungen
• Mit Leistungsbudget vergleichen
• Planen Sie Folgetests nach Optimierungen

---

Häufig gestellte Fragen

Sollten wir die Testproduktion oder das Staging laden?

Wenn möglich beides. Staging für regelmäßige Tests und CI/CD-Integration. Produktion zur regelmäßigen Validierung (während verkehrsarmer Zeiten), da sich das Staging häufig in der Datenbankgröße, der Cache-Wärme, der CDN-Konfiguration und der Netzwerktopologie unterscheidet. Wenn Sie nur eine Umgebung testen können, testen Sie das Staging, aber machen Sie es so produktionsähnlich wie möglich.

Wie oft sollten wir Auslastungstests durchführen?

Rauchtests bei jeder Bereitstellung (automatisiert in CI/CD). Volllasttests wöchentlich oder vor Hauptversionen. Stresstests vierteljährlich oder vor bekanntermaßen stark frequentierten Ereignissen (Verkäufe, Markteinführungen). Halten Sie vierteljährlich Tests ab, um Speicherlecks und langfristige Verschlechterungen zu erkennen.

Wie führen wir einen Lasttest eines ERP-Systems durch?

Beim ERP-Lasttest müssen gleichzeitige Benutzer simuliert werden, die verschiedene Aufgaben ausführen: Rechnungen erstellen, Bestellungen erstellen, Berichte ausführen, Daten importieren. Konzentrieren Sie sich auf die schwersten Vorgänge (Berichterstellung, Datenimporte) und die gleichzeitigsten Vorgänge (Auftragseingabe während der Spitzenzeiten). ECOSIRE bietet im Rahmen unserer Supportleistungen Odoo-Leistungstests an.

Was ist eine realistische Bedenkzeit zwischen Anfragen?

Für E-Commerce-Browsing: 2–5 Sekunden. Zum Ausfüllen des Formulars: 10–30 Sekunden. Zur Kasse: 15–60 Sekunden. Für Administrator-/ERP-Nutzung: 5–15 Sekunden. Fügen Sie Ihren Belastungstests immer eine zufällige Bedenkzeit hinzu – konstante Intervalle führen zu unrealistischen synchronisierten Belastungsmustern.

---

Was als nächstes kommt

Lasttests decken Engpässe auf, die Ihre Optimierungsbemühungen leiten. Führen Sie anschließend Datenbankskalierung für Datenbankengpässe, CDN-Optimierung für die Bereitstellung statischer Assets und automatische Skalierung für elastische Kapazität durch.

Kontaktieren Sie ECOSIRE für Leistungstests und -optimierungen oder erkunden Sie unseren DevOps-Leitfaden für die vollständige Infrastrukturstrategie.

---

Herausgegeben von ECOSIRE – Unterstützung von Unternehmen bei der Entwicklung von Anwendungen, die unter Druck funktionieren.