Welche Auswirkungen haben LAN, WLAN, Remote Verbindungen (HomeOffice) auf die Performance ?

Warum dauern Datenbankzugriffe über WLAN länger als über LAN?

Der Unterschied hat mehrere Ursachen, die sich gegenseitig verstärken können:

1. Latenz (Ping)

Das ist der Hauptfaktor. LAN-Verbindungen haben typischerweise eine Latenz von < 1 ms, WLAN hingegen 5–30 ms (je nach Standard und Umgebung).

Bei Datenbankabfragen ist das deshalb kritisch, weil MariaDB oft viele kleine Roundtrips macht:

• TCP-Handshake
• MySQL-Protokoll-Handshake (3–5 Pakete nur für den Verbindungsaufbau)
• Query senden → Antwort empfangen

Wenn jeder Roundtrip 10 ms länger dauert und du 10 Roundtrips hast, summiert sich das schnell auf +100 ms allein durch WLAN-Latenz.

2. Physikalisches Medium & Kollisionen

WLAN teilt sich den Kanal mit allen anderen Geräten im gleichen Frequenzband – Nachbarn eingeschlossen.

3. Protokoll-Overhead (CSMA/CA)

WLAN verwendet „Collision Avoidance": Bevor ein Paket gesendet wird, „lauscht" das Gerät ob der Kanal frei ist, und wartet ggf. eine zufällige Backoff-Zeit. Das fügt pro Paket zusätzliche Mikro- bis Millisekunden hinzu.

4. Retransmissions & Paketfehler

Funkverbindungen sind fehleranfälliger als Kabel. Verlorene Pakete müssen auf TCP-Ebene erneut übertragen werden. MariaDB selbst merkt davon nichts – aber die Verbindung wartet, bis TCP das Paket neu liefert.

5. WLAN Power-Saving & Buffering

Viele WLAN-Clients aktivieren Power-Save-Modus – dabei schläft das Funkmodul kurzzeitig und Pakete werden am Access Point gepuffert. Das kann vereinzelt mehrere Millisekunden extra kosten, gerade bei der ersten Abfrage nach einer Pause.

Zusammenfassung

LAN:  [Query] ──────── 0,5 ms ──────── [Antwort]
WLAN: [Query] ── 15 ms ── (Retry?) ── 15 ms ── [Antwort]
       └─ Latenz  └─ CSMA/CA  └─ Rückweg-Latenz

Faustregel: Nicht der Durchsatz (Bandbreite) ist das Problem – Datenbankabfragen sind meist klein. Es ist die Latenz pro Roundtrip, die sich bei vielen kleinen Transaktionen multipliziert.

Ja, massiv – hier ist warum:

Die Verbindungskette im Homeoffice:

Im Büro war es noch simpel:

[App] ──LAN/WLAN──> [MariaDB-Server]
        1–30 ms

Im Homeoffice sieht die Kette so aus:

[App auf Desktop] → [Heimrouter] → [Internet] → [Firmen-Router/VPN-Gateway] → [MariaDB-Server]
      WLAN/LAN          DSL/Kabel      WAN            VPN-Tunnel                  LAN
      0–30 ms          5–20 ms       10–80 ms          5–30 ms                   <1 ms

Jede Station addiert Latenz. Realistisch sind das schnell 50–150 ms pro Roundtrip – statt vorher 1–30 ms.

Die drei neuen Problemquellen

1.  Internet-Latenz (WAN)

Das Internet ist kein direktes Kabel. Pakete durchlaufen mehrere Routing-Hops, und die physikalische Distanz spielt eine Rolle. Von Bochum zu einem Rechenzentrum in Frankfurt sind das z.B. schon 10–20 ms – zu München oder Hamburg mehr.

2.  VPN-Overhead

Fast alle Firmen setzen VPN ein (OpenVPN, WireGuard, IPSec o.ä.). Das bedeutet:

3. Heimnetz-Qualität

Zu Hause ist die Infrastruktur nicht für Business-Traffic ausgelegt:

• DSL-Upload ist oft schwach (10–50 Mbit/s) – und beim Senden von Queries zählt der Upload
• WLAN zu Hause ist meist Consumer-Qualität
• Shared Medium: andere Haushaltsgeräte, Streaming, etc. konkurrieren um Bandbreite

pdm4cad / erp4cad nutzen das Connection Polling um die Handshakes und Roundtrips zu minimieren.

Mittelfristig – architektonisch:

- Anwendung auf einen Server im Firmennetz verlagern
   → Nur das UI läuft im Homeoffice (RDP / Thin Client)
   → App ↔ DB bleibt im LAN!

Der wichtigste Tipp

Die Anwendung und die Datenbank sollten immer im gleichen Netz liegen. Was über das WAN geht, sollte nur das UI sein – nicht die DB-Kommunikation.

Das klassische Muster dafür ist ein RDP/Citrix-Desktop im Firmennetz, oder eine Web-Anwendung, die serverseitig läuft. Dann ist die Latenz zwischen App und DB wieder < 1 ms, egal wo du sitzt.