# 7.7 Netzwerk oder Anwendung ist langsam

**1. Ziel dieser Seite**

Die Meldung „Das Netzwerk ist langsam“ beschreibt zunächst nur die Wahrnehmung des Benutzers. Die tatsächliche Ursache kann unter anderem im Client, im Netzwerk, auf dem Server, im Storage, in der Datenbank oder in der Anwendung liegen.

Diese Seite zeigt, wie ein Leistungsproblem systematisch eingegrenzt wird.

Ziel ist die Unterscheidung zwischen:

- langsamem Client,
- langsamem Netzwerk,
- hoher Latenz,
- Paketverlust,
- geringer verfügbarer Bandbreite,
- ausgelastetem WLAN,
- langsamem VPN,
- überlastetem Server,
- hoher Storage-Latenz,
- blockierter Datenbank,
- langsamem DNS,
- fehlerhaftem Serverknoten,
- Anwendungs- oder Schnittstellenproblem.

---

**2. „Langsam“ messbar beschreiben**

Ungeeignet:

```text
Das Netzwerk ist langsam.
```

Besser:

```text
Das Öffnen einer 20-MB-Datei vom Dateiserver dauert seit 09:30 Uhr
ungefähr 45 Sekunden. Normalerweise dauert es weniger als 5 Sekunden.
Betroffen sind drei Benutzer im zweiten Obergeschoss.
Internetseiten und das Standardgateway reagieren normal.
```

Zu erfassen sind:

- genaue Benutzeraktion,
- betroffene Anwendung,
- betroffene Datei oder Funktion,
- Startzeitpunkt,
- Dauer,
- Häufigkeit,
- betroffene Benutzer,
- betroffene Clients,
- Standort,
- LAN, WLAN oder VPN,
- internes oder externes Ziel,
- erwartete Dauer,
- tatsächlich gemessene Dauer,
- Fehlermeldungen,
- durchgeführte Änderungen.

**Beispiel**

| Merkmal | Beobachtung |
|---|---|
| Aktion | Öffnen einer Datei vom Dateiserver |
| Dateigröße | 20 MB |
| Normalzustand | 3 bis 5 Sekunden |
| aktueller Zustand | 40 bis 50 Sekunden |
| Beginn | seit ungefähr 09:30 Uhr |
| Betroffene | drei Benutzer |
| Standort | zweites Obergeschoss |
| Verbindung | WLAN |
| Internet | normal |
| Gateway | normal erreichbar |
| Dateiserver | hohe Antwortzeit |

Erst durch einen solchen Vergleich wird aus einer subjektiven Meldung ein messbares Problem.

---

**3. Wichtige Leistungsbegriffe unterscheiden**

| Begriff | Bedeutung |
|---|---|
| Latenz | Zeit, die ein Datenpaket oder eine Anfrage bis zur Antwort benötigt |
| Paketverlust | Anteil der Pakete, die ihr Ziel nicht erreichen |
| Bandbreite | theoretisch oder technisch verfügbare Übertragungskapazität |
| Durchsatz | tatsächlich übertragene Datenmenge pro Zeiteinheit |
| Jitter | Schwankung der Laufzeit aufeinanderfolgender Pakete |
| Antwortzeit | gesamte Dauer einer Anfrage aus Benutzersicht |
| IOPS | Anzahl der Ein- und Ausgabeoperationen eines Speichers pro Sekunde |
| Storage-Latenz | Wartezeit einer Speicheroperation |
| CPU-Auslastung | Anteil der aktuell verwendeten Prozessorleistung |
| Arbeitsspeicherauslastung | Belegung des physischen Arbeitsspeichers |
| Warteschlange | Anforderungen, die auf Verarbeitung oder Übertragung warten |
| Retransmission | erneute Übertragung verlorener oder nicht bestätigter TCP-Daten |
| Applikationslatenz | Zeit, welche die Anwendung für die Verarbeitung benötigt |

Eine schnelle Netzwerkverbindung garantiert keinen hohen Anwendungsdurchsatz.

**Beispiel**

```text
Verbindungsgeschwindigkeit: 1 Gbit/s
tatsächlicher Dateidurchsatz: 8 Mbit/s
```

Die angezeigte Verbindungsgeschwindigkeit beschreibt nur die ausgehandelte Verbindung. Sie beweist nicht, dass die gesamte Strecke oder das Zielsystem diese Datenrate bereitstellen kann.

---

**4. Mögliche Ursachenbereiche**

```text
Benutzeraktion
      ↓
Client
      ↓
lokale Verbindung
      ↓
Switch, WLAN oder VPN
      ↓
Routing, Firewall oder WAN
      ↓
Server
      ↓
Anwendung
      ↓
Datenbank oder Storage
```

Eine Verzögerung kann an jeder Stelle dieser Kette entstehen.

**Client**

- hohe CPU-Auslastung,
- unzureichender Arbeitsspeicher,
- langsamer Datenträger,
- Hintergrundprogramme,
- Virenscanner,
- fehlerhafter Netzwerktreiber,
- Energiesparmodus,
- Browsererweiterungen,
- lokaler DNS-Cache,
- defekte Netzwerkkarte.

**Netzwerk**

- Paketverlust,
- hohe Latenz,
- Interface-Fehler,
- Duplex- oder Geschwindigkeitsproblem,
- ausgelasteter Uplink,
- Queue Drops,
- fehlerhaftes Kabel,
- überlastetes WLAN,
- Roaming,
- VPN-Überlastung,
- MTU-Problem,
- fehlerhaftes Routing,
- langsame Namensauflösung.

**Server**

- hohe CPU-Auslastung,
- zu wenig Arbeitsspeicher,
- Paging oder Swapping,
- hohe Storage-Latenz,
- volle Datenträger,
- überlastete Netzwerkschnittstelle,
- zu viele gleichzeitige Sitzungen,
- blockierte Prozesse,
- Virenscan,
- Backup,
- Snapshot,
- überlasteter Hypervisor.

**Anwendung und Datenbank**

- langsame Datenbankabfrage,
- fehlender Datenbankindex,
- Datenbanksperre,
- erschöpfter Verbindungspool,
- langsame API,
- externer Dienst,
- fehlerhafter Serverknoten,
- Anwendungsfehler,
- ungeeignete Zeitüberschreitung,
- große oder ineffiziente Abfrage,
- überlastete Hintergrundverarbeitung.

---

**5. Zuerst den Umfang bestimmen**

Zu klären ist:

1. Ist nur ein Benutzer betroffen?
2. Sind mehrere Benutzer betroffen?
3. Ist nur ein Standort betroffen?
4. Sind nur WLAN-Benutzer betroffen?
5. Sind auch kabelgebundene Clients betroffen?
6. Ist nur eine Anwendung langsam?
7. Sind mehrere Dienste desselben Servers betroffen?
8. Sind interne und externe Ziele betroffen?
9. Tritt das Problem zu einer bestimmten Uhrzeit auf?
10. Tritt es nur bei einer bestimmten Datenmenge auf?

**Schnelle Eingrenzung**

| Beobachtung | Wahrscheinlicher Prüfbereich |
|---|---|
| nur ein Client betroffen | Client, Treiber, Kabel, WLAN oder lokale Software |
| mehrere Clients gleichzeitig betroffen | gemeinsame Infrastruktur oder zentraler Dienst |
| nur ein Standort betroffen | Standortanbindung, Switch, WLAN oder WAN |
| nur WLAN betroffen | Funkstrecke, Access Point, Kanal oder Roaming |
| LAN und WLAN betroffen | gemeinsamer Netzwerkpfad, Server oder Anwendung |
| nur eine Anwendung betroffen | Anwendung, Datenbank, API oder Sitzung |
| mehrere Dienste eines Servers betroffen | Server, Betriebssystem, Storage oder Hypervisor |
| alle internen Dienste langsam | Netzwerk, DNS, Firewall oder zentrale Infrastruktur |
| nur Internet langsam | WAN, Provider, Proxy oder externe Ziele |
| nur große Dateien langsam | Durchsatz, Paketverlust, Storage oder Übertragungsweg |
| kleine Anfragen bereits langsam | Latenz, DNS, Anwendung oder Datenbank |

---

**6. Vergleich mit einer funktionierenden Referenz**

Ein Vergleichssystem sollte möglichst ähnlich sein:

- gleicher Standort,
- gleiches Netzwerk,
- gleiche Anwendung,
- gleiche Berechtigung,
- gleiche Datenmenge,
- gleicher Server,
- ähnliche Hardware,
- möglichst gleicher Zeitpunkt.

**Beispiel**

| Prüfung | betroffener Client | Vergleichsclient |
|---|---:|---:|
| Gateway-Latenz | 2 ms | 2 ms |
| Server-Latenz | 3 ms | 3 ms |
| Dateiübertragung | 4 MB/s | 85 MB/s |
| CPU-Auslastung | 15 % | 20 % |
| Datenträgerauslastung | 100 % | 8 % |

In diesem Beispiel ist der Netzwerkpfad zunächst unauffällig. Die lokale Datenträgerauslastung des betroffenen Clients ist dagegen auffällig.

---

**7. Baseline festlegen**

Ein Messwert ist nur aussagekräftig, wenn bekannt ist, welcher Wert normalerweise erreicht wird.

**Beispiel**

```text
Normale Antwortzeit:       200 bis 400 ms
Aktuelle Antwortzeit:      4 bis 8 Sekunden
Normale Dateiübertragung:  80 bis 95 MB/s
Aktuelle Übertragung:      5 bis 12 MB/s
Normale Storage-Latenz:    2 bis 8 ms
Aktuelle Storage-Latenz:   80 bis 250 ms
```

Mögliche Baselines:

- Antwortzeit einer Anwendung,
- Laufzeit einer Datenbankabfrage,
- Ping-Latenz,
- Paketverlust,
- DNS-Antwortzeit,
- Dateidurchsatz,
- CPU-Auslastung,
- Speicherauslastung,
- Storage-Latenz,
- Anzahl gleichzeitiger Sitzungen,
- Fehlerrate,
- Warteschlangenlänge.

Messungen sollten möglichst unter vergleichbaren Bedingungen erfolgen.

---

**8. Lokalen Client prüfen**

Unter Windows:

```powershell
Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet
```

Netzwerkadapter anzeigen:

```powershell
Get-NetAdapter |
    Format-Table Name, Status, LinkSpeed, InterfaceDescription
```

Adapterstatistiken:

```powershell
Get-NetAdapterStatistics
```

Aktuelle IP-Konfiguration:

```cmd
ipconfig /all
```

Unter Linux:

```bash
top
```

Alternativ, sofern installiert:

```bash
htop
```

Arbeitsspeicher:

```bash
free -h
```

Datenträgerbelegung:

```bash
df -h
```

Netzwerkschnittstellen:

```bash
ip link show
```

Statistiken:

```bash
ip -s link show
```

Zu prüfen sind:

- CPU-Spitzen,
- Speicherdruck,
- Paging oder Swapping,
- Datenträgerauslastung,
- Hintergrundprozesse,
- Synchronisationsprogramme,
- Virenscanner,
- Softwareupdates,
- Treiberstatus,
- ausgehandelte Verbindungsgeschwindigkeit,
- Interface-Fehler,
- Energiesparzustände.

Ein ausgelasteter Client kann eine langsame Anwendung verursachen, obwohl Netzwerk und Server ordnungsgemäß arbeiten.

---

**9. Latenz und Paketverlust messen**

Unter Windows:

```cmd
ping -t <ziel>
```

Beispiel:

```cmd
ping -t 192.0.2.10
```

Unter Linux oder macOS:

```bash
ping <ziel>
```

Es sollten mehrere Ziele verglichen werden:

```text
Client → Standardgateway
Client → interner Server
Client → externes Referenzziel
```

**Auswertung**

| Gateway | interner Server | externes Ziel | Mögliche Eingrenzung |
|---|---|---|---|
| langsam | langsam | langsam | Clientzugang oder lokales Netzwerk |
| normal | langsam | normal | interner Pfad oder Servernetz |
| normal | normal | langsam | WAN, Provider oder externer Pfad |
| normal | normal | normal | Anwendung, Port, Serverprozess oder Datenbank |
| Paketverlust | Paketverlust | Paketverlust | lokale Verbindung oder gemeinsamer Uplink |

Ping prüft ICMP-Erreichbarkeit. Eine normale Ping-Antwort beweist nicht, dass die Anwendung schnell arbeitet.

---

**10. Netzwerkpfad untersuchen**

Unter Windows:

```cmd
tracert <ziel>
```

Unter Linux:

```bash
traceroute <ziel>
```

Unter macOS:

```bash
traceroute <ziel>
```

Falls vorhanden, kann eine fortlaufende Pfadanalyse durchgeführt werden:

```bash
mtr <ziel>
```

Zu prüfen sind:

- auffällige Latenzsprünge,
- wechselnde Pfade,
- Paketverlust,
- Routingänderungen,
- Unterschiede zwischen betroffenen und funktionierenden Clients.

Ein Router muss ICMP-Antworten nicht mit derselben Priorität wie weitergeleiteten Verkehr behandeln. Ein auffälliger Zwischenknoten allein beweist deshalb noch keinen Fehler. Entscheidend ist, ob die Beeinträchtigung auch an nachfolgenden Zielen sichtbar bleibt.

---

**11. TCP-Port getrennt prüfen**

Unter Windows:

```powershell
Test-NetConnection <server> -Port <port>
```

Beispiel:

```powershell
Test-NetConnection fileserver.example.local -Port 445
```

Weitere Beispiele:

```powershell
Test-NetConnection webserver.example.local -Port 443
```

```powershell
Test-NetConnection dbserver.example.local -Port 1433
```

Unter Linux oder macOS, sofern Netcat vorhanden ist:

```bash
nc -vz <server> <port>
```

Beispiel:

```bash
nc -vz webserver.example.local 443
```

Damit wird geprüft, ob der TCP-Verbindungsaufbau möglich ist. Die tatsächliche Antwortzeit der Anwendung wird dadurch noch nicht vollständig gemessen.

---

**12. Anwendungsantwort mit curl messen**

Gesamte Antwortzeit:

```bash
curl \
    -o /dev/null \
    -s \
    -w "DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\nErstes Byte: %{time_starttransfer}\nGesamt: %{time_total}\n" \
    https://example.com/
```

Beispielausgabe:

```text
DNS:         0.012
TCP:         0.028
TLS:         0.071
Erstes Byte: 3.842
Gesamt:      3.901
```

Interpretation:

- DNS langsam: Namensauflösung untersuchen,
- TCP langsam: Netzwerkpfad oder Zielsystem prüfen,
- TLS langsam: Zertifikatsprüfung, Proxy oder Serverlast prüfen,
- erstes Byte langsam: Anwendung, Server oder Datenbank prüfen,
- Download nach dem ersten Byte langsam: Durchsatz oder Datenmenge prüfen.

**Vergleich**

```text
DNS:         0,012 Sekunden
TCP:         0,028 Sekunden
TLS:         0,071 Sekunden
Erstes Byte: 3,842 Sekunden
```

Das Netzwerk baut die Verbindung schnell auf. Die lange Wartezeit bis zum ersten Byte weist eher auf die Verarbeitung im Zielsystem hin.

---

**13. DNS-Antwortzeit prüfen**

Unter Windows:

```powershell
Measure-Command {
    Resolve-DnsName <hostname>
}
```

Einzelne DNS-Abfrage:

```powershell
Resolve-DnsName <hostname>
```

Unter Linux oder macOS, sofern `dig` vorhanden ist:

```bash
dig <hostname>
```

Kurze Ausgabe:

```bash
dig <hostname> +stats
```

Zu prüfen sind:

- Antwortzeit,
- verwendeter DNS-Server,
- unterschiedliche Antworten,
- Zeitüberschreitungen,
- fehlerhafte Weiterleitung,
- IPv4- und IPv6-Verhalten,
- Suchdomänen,
- Split-DNS,
- mehrere Zieladressen.

**Beispiel**

```text
Aufruf über IP-Adresse:  0,4 Sekunden
Aufruf über Hostnamen:   5,2 Sekunden
```

Dieser Unterschied weist auf die Namensauflösung hin. Er beweist noch nicht, welcher DNS-Server oder welche DNS-Konfiguration die Verzögerung verursacht.

---

**14. Durchsatz messen**

Für eine kontrollierte Netzwerkmessung kann `iperf3` verwendet werden. Dafür wird auf einem autorisierten Zielsystem ein `iperf3`-Server benötigt.

Server:

```bash
iperf3 -s
```

Client:

```bash
iperf3 -c <server-ip>
```

Messung in Gegenrichtung:

```bash
iperf3 -c <server-ip> -R
```

Mehrere parallele Verbindungen:

```bash
iperf3 -c <server-ip> -P 4
```

UDP-Tests dürfen nur kontrolliert und mit begrenzter Bandbreite durchgeführt werden:

```bash
iperf3 -c <server-ip> -u -b 10M
```

Zu vergleichen sind:

- Senderichtung,
- Empfangsrichtung,
- LAN,
- WLAN,
- VPN,
- betroffener Client,
- Referenzclient,
- verschiedene Zeitpunkte.

**Wichtig**

Ein unkontrollierter Durchsatztest kann produktive Verbindungen beeinträchtigen. Zielsystem, Testdauer und erzeugte Last müssen abgestimmt sein.

---

**15. Dateitransfer richtig bewerten**

Ein Dateitransfer misst nicht ausschließlich das Netzwerk.

Beteiligt sind:

```text
Quelldatenträger
      ↓
Quellsystem
      ↓
Netzwerk
      ↓
Zielsystem
      ↓
Zieldatenträger
```

Mögliche Begrenzungen:

- langsamer Quelldatenträger,
- langsamer Zieldatenträger,
- Virenscanner,
- Dateisystem,
- Verschlüsselung,
- SMB- oder NFS-Konfiguration,
- viele kleine Dateien,
- Kompression,
- CPU-Auslastung,
- Netzwerkdurchsatz,
- Storage-Latenz.

**Beispiel**

```text
Eine Datei mit 10 GB:          80 MB/s
100.000 sehr kleine Dateien:    8 MB/s
```

Viele kleine Dateien erzeugen wesentlich mehr Verwaltungs- und Speicheroperationen. Die niedrigere Übertragungsrate beweist deshalb nicht automatisch ein Netzwerkproblem.

---

**16. Interface-Fehler und Drops prüfen**

Unter Windows:

```powershell
Get-NetAdapterStatistics
```

Unter Linux:

```bash
ip -s link show
```

Auf einem verwalteten Switch müssen die herstellerspezifischen Diagnosebefehle verwendet werden.

Zu beobachten sind:

- CRC-/FCS-Fehler,
- Input Errors,
- Output Errors,
- Discards,
- Queue Drops,
- Interface Resets,
- Kollisionen,
- Link-Flaps,
- Geschwindigkeits- und Duplexaushandlung.

Zähler müssen als Verlauf betrachtet werden.

**Beispiel**

```text
09:00 Uhr:  15 CRC-Fehler
09:30 Uhr:  15 CRC-Fehler
10:00 Uhr:  15 CRC-Fehler
```

Der Zähler steigt nicht. Die Fehler können aus einem früheren Zeitraum stammen.

```text
09:00 Uhr:    15 CRC-Fehler
09:30 Uhr:   280 CRC-Fehler
10:00 Uhr: 4.500 CRC-Fehler
```

Der Zähler nimmt aktuell zu und weist auf ein Problem des physischen Übertragungswegs hin.

---

**17. Duplex und Verbindungsgeschwindigkeit prüfen**

Mögliche Symptome:

- geringer Durchsatz,
- hohe Anzahl von Fehlern,
- Kollisionen,
- stark unterschiedliche Sende- und Empfangsleistung,
- Verbindung handelt nur 100 Mbit/s statt 1 Gbit/s aus.

Zu prüfen sind:

- Clientadapter,
- Switchport,
- Kabelkategorie,
- Stecker,
- Dockingstation,
- Medienkonverter,
- Transceiver,
- automatische Aushandlung.

Geschwindigkeit und Duplex dürfen nicht wahllos fest eingestellt werden. Beide Seiten müssen zusammenpassen und die Änderung muss dokumentiert sowie freigegeben sein.

---

**18. WLAN-Leistung untersuchen**

Bei WLAN-Verbindungen sind zusätzlich zu betrachten:

- Signalstärke,
- Signal-Rausch-Abstand,
- Kanalauslastung,
- Retry-Rate,
- verwendetes Frequenzband,
- Kanalbreite,
- Anzahl aktiver Clients,
- Airtime,
- Roaming,
- Access-Point-Auslastung,
- DFS-Kanalwechsel,
- Störquellen,
- AP-Uplink,
- PoE-Versorgung.

Unter Windows:

```cmd
netsh wlan show interfaces
```

WLAN-Bericht:

```cmd
netsh wlan show wlanreport
```

Wichtiger Vergleich:

| Test | LAN | WLAN | Eingrenzung |
|---|---|---|---|
| Anwendung | schnell | langsam | WLAN oder Access Point |
| Anwendung | langsam | langsam | gemeinsamer Pfad, Server oder Anwendung |
| nur ein WLAN-Client langsam | – | betroffen | Client, Treiber, Standort oder Funkband |
| alle Clients eines AP langsam | – | betroffen | Access Point, Kanal, Uplink oder PoE |

Ein hoher angezeigter WLAN-Verbindungswert entspricht nicht automatisch dem tatsächlichen Nutzdurchsatz.

---

**19. VPN-Verbindung untersuchen**

Mögliche Ursachen:

- hohe Internetlatenz,
- Paketverlust,
- überlastetes VPN-Gateway,
- Verschlüsselungslast,
- ungeeignete MTU,
- getunnelter Internetverkehr,
- langsamer DNS-Server,
- geografische Entfernung,
- WLAN-Probleme des Benutzers,
- Bandbreitenbegrenzung,
- Neuaufbau des Tunnels.

Zu vergleichen sind:

```text
ohne VPN → internes Testziel, sofern autorisiert erreichbar
mit VPN  → internes Testziel
mit VPN  → Standardgateway des lokalen Netzes
mit VPN  → VPN-Gateway
```

Außerdem sollte geprüft werden:

- betrifft es alle VPN-Benutzer,
- betrifft es nur einen Internetanbieter,
- tritt es nur zu bestimmten Zeiten auf,
- ist nur eine Anwendung betroffen,
- sind Senden und Empfangen unterschiedlich langsam,
- steigt die CPU-Auslastung des VPN-Gateways,
- treten Tunnelabbrüche oder Neuverbindungen auf.

VPN- oder Sicherheitsfunktionen dürfen nicht zur Diagnose umgangen werden.

---

**20. Serverressourcen prüfen**

Wichtige Messwerte:

- CPU-Auslastung,
- CPU-Warteschlange,
- Arbeitsspeicher,
- Paging oder Swapping,
- Datenträgerauslastung,
- Storage-Latenz,
- freie Speicherkapazität,
- Netzwerkauslastung,
- aktive Sitzungen,
- Prozessanzahl,
- Container- oder VM-Grenzen,
- Hypervisor-Auslastung.

Unter Linux:

```bash
uptime
```

```bash
free -h
```

```bash
df -h
```

```bash
top
```

Falls installiert:

```bash
vmstat 1
```

```bash
iostat -xz 1
```

Unter Windows können Task-Manager, Ressourcenmonitor, Leistungsüberwachung und PowerShell verwendet werden.

Beispiel für Prozesse mit hoher CPU-Zeit:

```powershell
Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, CPU, WorkingSet
```

Ein einzelner aktueller Messwert reicht bei sporadischen Problemen nicht aus. Die Werte müssen während der tatsächlichen Verzögerung aufgezeichnet werden.

---

**21. CPU-Auslastung richtig interpretieren**

Eine hohe CPU-Auslastung kann auf einen Engpass hinweisen, muss aber im Zusammenhang betrachtet werden.

Zu prüfen sind:

- Gesamtauslastung,
- Auslastung einzelner Kerne,
- Prozess mit hoher CPU-Nutzung,
- Laufzeit der hohen Last,
- Warteschlangen,
- virtuelle CPU-Zuteilung,
- CPU-Limits von Containern,
- Steal Time bei virtuellen Systemen,
- thermische Drosselung.

**Beispiel**

```text
Gesamtauslastung: 35 %
Anwendungsprozess: ein Prozesskern dauerhaft bei 100 %
```

Eine nicht ausreichend parallelisierte Anwendung kann bereits durch einen vollständig ausgelasteten Kern begrenzt werden, obwohl die Gesamtauslastung unauffällig wirkt.

---

**22. Arbeitsspeicher und Paging prüfen**

Hohe Speicherbelegung allein beweist keinen Fehler. Betriebssysteme nutzen freien Arbeitsspeicher häufig als Cache.

Wichtiger sind:

- verfügbarer Arbeitsspeicher,
- Paging oder Swapping,
- Speicherdruck,
- Speicherwachstum eines Prozesses,
- Out-of-Memory-Ereignisse,
- Container- oder VM-Limits,
- wiederholte Prozessabbrüche.

**Typische Wirkung**

```text
Arbeitsspeicher reicht nicht aus
            ↓
Auslagerung auf Datenträger
            ↓
Storage-Latenz steigt
            ↓
Anwendung reagiert langsam
```

Deshalb müssen Arbeitsspeicher- und Storage-Messwerte gemeinsam betrachtet werden.

---

**23. Storage-Latenz untersuchen**

Eine hohe Datenträgerauslastung bedeutet nicht automatisch einen hohen Datendurchsatz. Viele kleine oder zufällige Operationen können einen Datenträger vollständig auslasten.

Zu prüfen sind:

- Lese- und Schreiblatenz,
- Warteschlangentiefe,
- IOPS,
- Durchsatz,
- freie Kapazität,
- Dateisystem,
- RAID-Zustand,
- Controllerzustand,
- Cache,
- SAN- oder NAS-Verbindung,
- Snapshots,
- Replikation,
- Backup,
- Virenscan,
- Thin Provisioning,
- Storage-Überbelegung.

**Beispiel**

```text
Netzwerkauslastung:  12 %
CPU-Auslastung:      30 %
Storage-Latenz:     180 ms
Anwendungsantwort:    8 s
```

Die niedrige Netzwerkauslastung spricht gegen einen reinen Bandbreitenengpass. Die hohe Storage-Latenz ist dagegen auffällig.

Hersteller- und betriebssystemspezifische Grenzwerte müssen anhand der jeweiligen Dokumentation und des normalen Betriebszustands bewertet werden.

---

**24. Datenbank als Ursache untersuchen**

Mögliche Ursachen:

- langsame Abfrage,
- fehlender Index,
- Datenbanksperre,
- Deadlock,
- zu viele gleichzeitige Verbindungen,
- erschöpfter Verbindungspool,
- hohe Storage-Latenz,
- Statistik- oder Wartungsproblem,
- große Ergebnismenge,
- ungeeigneter Ausführungsplan,
- Replikationsverzögerung.

Zu vergleichen sind:

- Dauer der Benutzeranfrage,
- Dauer der zugehörigen Datenbankabfrage,
- Wartezeiten,
- Sperren,
- Anzahl aktiver Verbindungen,
- CPU- und Storage-Auslastung,
- Zeitpunkt von Wartungsaufgaben,
- Verhalten vergleichbarer Abfragen.

**Beispiel**

```text
TCP-Verbindung zum Webserver:      20 ms
Antwort des Webservers:             6 s
Datenbankabfrage:                 5,7 s
```

Das Netzwerk ist in diesem Beispiel nicht der größte Zeitanteil. Die Datenbankabfrage bestimmt nahezu die gesamte Antwortzeit.

Produktive Abfragen dürfen nicht unkontrolliert wiederholt oder verändert werden. Datenbankdiagnosen müssen mit den vorgesehenen Werkzeugen und Berechtigungen erfolgen.

---

**25. Anwendungs- und API-Abhängigkeiten prüfen**

Eine Anwendung kann von mehreren Diensten abhängig sein:

```text
Client
  ↓
Webanwendung
  ↓
Authentifizierungsdienst
  ↓
API
  ↓
Datenbank
  ↓
Storage
```

Zu prüfen sind:

- Antwortzeit jeder Abhängigkeit,
- externe APIs,
- Authentifizierungsdienst,
- Verzeichnisdienst,
- DNS,
- Proxy,
- Nachrichtenwarteschlange,
- Datenbank,
- Storage,
- Cache,
- Rate Limits,
- Zeitüberschreitungen.

**Beispiel**

```text
Anwendung selbst:          100 ms
externe API:             4.800 ms
Gesamtantwort:           5.100 ms
```

Aus Benutzersicht ist die Anwendung langsam. Die eigentliche Verzögerung entsteht jedoch bei einer externen API.

---

**26. Load Balancer und mehrere Serverknoten prüfen**

Bei verteilten Anwendungen kann nur ein einzelner Knoten langsam sein.

**Beispiel**

| Zielknoten | Antwortzeit |
|---|---:|
| Webserver 1 | 250 ms |
| Webserver 2 | 230 ms |
| Webserver 3 | 8.400 ms |
| Zugriff über Load Balancer | wechselnd zwischen schnell und langsam |

Mögliche Ursachen des einzelnen Knotens:

- andere Konfiguration,
- fehlerhafte Softwareversion,
- hohe CPU-Auslastung,
- langsames Storage,
- fehlerhaftes Zertifikat,
- fehlende Verbindung zur Datenbank,
- defekter Cache,
- Hintergrundprozess,
- ungleiche Lastverteilung.

Alle Knoten müssen einzeln verglichen werden. Ein gelegentlich langsamer Zugriff über den Load Balancer kann entstehen, wenn nur ein Teil der Anfragen an den fehlerhaften Knoten gelangt.

---

**27. Zeitgesteuerte Last berücksichtigen**

Leistungsprobleme können regelmäßig mit anderen Prozessen zusammenfallen:

- Backup,
- Snapshot,
- Replikation,
- Virenscan,
- Softwareverteilung,
- Update,
- Datenimport,
- Export,
- Berichterstellung,
- Indexierung,
- Datenbankwartung,
- Logrotation,
- Cloud-Synchronisation.

**Beispiel**

```text
02:00:00 Backup startet
02:00:12 Storage-Latenz steigt
02:00:18 Datenbankabfragen werden langsamer
02:00:25 Anwendung überschreitet Zeitlimit
02:20:00 Backup endet
02:20:15 Storage-Latenz normalisiert sich
```

Eine gemeinsame Zeitleiste zeigt die mögliche Abhängigkeit.

Der zeitliche Zusammenhang ist ein Hinweis. Die Ursache muss durch Messwerte und gegebenenfalls eine kontrollierte Änderung bestätigt werden.

---

**28. Paketmitschnitt gezielt einsetzen**

Ein Paketmitschnitt kann unter anderem zeigen:

- TCP-Retransmissions,
- Verbindungsabbrüche,
- verzögerte Bestätigungen,
- DNS-Zeitüberschreitungen,
- lange Pausen zwischen Anfrage und Antwort,
- wiederholte Verbindungsaufbauten,
- TCP-Zero-Window-Ereignisse,
- TLS-Verbindungsaufbau,
- unterschiedliche Serverziele.

Beispiel mit `dumpcap`:

```bash
dumpcap \
    -i 1 \
    -f "host 192.0.2.45" \
    -b duration:300 \
    -b files:12 \
    -w langsame-anwendung.pcapng
```

Dabei gelten folgende Regeln:

- Mitschnitt autorisieren lassen,
- richtige Schnittstelle auswählen,
- Capture-Filter begrenzen,
- Speicherbedarf begrenzen,
- Datenschutz berücksichtigen,
- Zeitpunkt des Problems dokumentieren,
- Mitschnitt nach der Diagnose beenden,
- Dateien geschützt speichern,
- Dateien anschließend geregelt löschen.

Ein Mitschnitt auf dem Client zeigt nicht automatisch alle Pakete anderer Systeme oder Netzwerksegmente.

---

**29. TCP-Retransmissions bewerten**

TCP überträgt verlorene Daten erneut. Viele erneute Übertragungen können den Durchsatz erheblich reduzieren.

Mögliche Ursachen:

- Paketverlust,
- fehlerhaftes Kabel,
- WLAN-Störungen,
- überlastete Warteschlangen,
- WAN-Probleme,
- fehlerhafter Netzwerkadapter,
- MTU-Problem,
- überlastetes Zielsystem.

**Vereinfachtes Beispiel**

```text
Datenpaket wird gesendet
        ↓
Paket geht verloren
        ↓
Bestätigung bleibt aus
        ↓
TCP wartet
        ↓
Daten werden erneut übertragen
```

Die Bandbreite kann technisch hoch sein, während der tatsächlich nutzbare Durchsatz durch Paketverlust stark sinkt.

---

**30. Ursache und Wartezeit trennen**

Eine langsame Anwendung kann in verschiedene Zeitanteile zerlegt werden.

**Beispiel**

| Verarbeitungsschritt | Dauer |
|---|---:|
| DNS-Auflösung | 20 ms |
| TCP-Verbindungsaufbau | 25 ms |
| TLS-Verbindungsaufbau | 70 ms |
| Webserververarbeitung | 180 ms |
| Datenbankabfrage | 4.800 ms |
| Übertragung der Antwort | 90 ms |
| Gesamtdauer | 5.185 ms |

Die Datenbankabfrage beansprucht den größten Teil der Gesamtdauer.

Dadurch kann die Diagnose auf den Bereich mit dem größten Zeitanteil konzentriert werden.

---

**31. Mehrere Systeme auf einer Zeitleiste vergleichen**

| Zeit | Client | Netzwerk | Server | Storage | Anwendung |
|---:|---|---|---|---|---|
| 09:59:50 | normal | normal | normal | 4 ms | 300 ms |
| 10:00:00 | Anfrage startet | normal | CPU 40 % | 8 ms | 400 ms |
| 10:00:05 | wartet | normal | CPU 45 % | 170 ms | 5 s |
| 10:00:10 | wartet | normal | CPU 48 % | 240 ms | 10 s |
| 10:00:15 | Antwort | normal | CPU 42 % | 12 ms | normal |

In diesem Beispiel steigen die Netzwerklatenz und CPU-Auslastung nicht auffällig. Die Storage-Latenz steigt dagegen zeitgleich mit der langsamen Anwendung.

---

**32. Hypothese messbar formulieren**

Ungeeignet:

```text
Der Server ist wahrscheinlich überlastet.
```

Besser:

```text
Wenn die Anwendung erneut länger als fünf Sekunden benötigt,
steigt vermutlich gleichzeitig die Storage-Latenz des Datenbankservers
auf mehr als 100 ms.
```

Prüfung:

```text
Anwendungsantwortzeit messen
Storage-Latenz aufzeichnen
Datenbankwartezeiten erfassen
Zeitstempel vergleichen
```

Eine gute Hypothese enthält:

- konkrete Komponente,
- erwarteten Messwert,
- erwartete Veränderung,
- Zeitfenster,
- Möglichkeit der Widerlegung.

---

**33. Kontrollierte Änderung durchführen**

Erst nach ausreichender Eingrenzung wird genau eine Änderung vorgenommen.

Mögliche Änderungen:

- defektes Kabel ersetzen,
- vorgesehenen Treiber aktualisieren,
- fehlerhaften Switchport wechseln,
- ungeeignete Sicherungszeit verschieben,
- fehlerhaften Serverknoten aus der Verteilung nehmen,
- abgestimmte Bandbreitensteuerung einrichten,
- Datenbankabfrage optimieren,
- fehlenden Index nach Prüfung ergänzen,
- Ressourcenlimit korrigieren,
- defekten Datenträger oder Access Point ersetzen.

Ungeeignet:

```text
Treiber aktualisieren, Kabel ersetzen, DNS ändern und Server neu starten.
```

Wenn mehrere Änderungen gleichzeitig durchgeführt werden, kann die wirksame Maßnahme nicht mehr eindeutig bestimmt werden.

---

**34. Rollback festlegen**

Vor jeder Änderung dokumentieren:

- ursprüngliche Konfiguration,
- ursprüngliche Version,
- Ausgangsmesswerte,
- verantwortliche Person,
- Änderungsfenster,
- erwartete Wirkung,
- Abbruchkriterium,
- Rückweg.

**Beispiel**

```text
Änderung:
Fehlerhaften Webserver 3 kontrolliert aus dem Load Balancer nehmen.

Erwartung:
Die wechselnden Antwortzeiten verschwinden.

Rollback:
Webserver 3 mit der ursprünglichen Gewichtung wieder aufnehmen.

Abbruchkriterium:
Verbleibende Knoten überschreiten die zulässige Auslastung.
```

---

**35. Verifikation**

Nach der Änderung müssen dieselben Messungen wie vorher wiederholt werden.

Zu prüfen sind:

- ursprüngliche Benutzeraktion,
- Antwortzeit,
- Latenz,
- Paketverlust,
- Durchsatz,
- Fehlerzähler,
- CPU-Auslastung,
- Arbeitsspeicher,
- Storage-Latenz,
- Datenbankwartezeit,
- Protokolle,
- Nebenwirkungen,
- Verhalten abhängiger Systeme.

**Beispiel**

```text
Vorher:
Antwortzeit:       6 bis 12 Sekunden
Storage-Latenz:   120 bis 260 ms
Fehlerhäufigkeit:  20 bis 30 Ereignisse pro Stunde

Nachher:
Antwortzeit:       250 bis 400 ms
Storage-Latenz:    3 bis 8 ms
Fehlerhäufigkeit:  0 Ereignisse in 48 Stunden
```

Ein einzelner erfolgreicher Test reicht nicht aus, wenn das Problem vorher nur gelegentlich auftrat.

---

**36. Beispiel „Netzwerk angeblich langsam“**

**Symptom**

Mehrere Benutzer melden, dass das Öffnen von Kundendatensätzen am Vormittag mehrere Sekunden dauert.

**Erste Messungen**

```text
Gateway-Latenz:             1 ms
Webserver-Latenz:           2 ms
Paketverlust:               0 %
TCP-Verbindungsaufbau:     20 ms
Zeit bis zum ersten Byte:   7 s
```

**Servermessungen**

```text
CPU-Auslastung:            35 %
Arbeitsspeicher:           unauffällig
Netzwerkauslastung:        10 %
Storage-Latenz:             6 ms
```

**Datenbankmessung**

```text
Abfragedauer:              6,7 s
Warteursache:              Datenbanksperre
```

**Festgestellte Ursache**

Ein zeitgleich laufender Import hielt eine Datenbanksperre. Netzwerk und Webserver waren nicht die Ursache.

**Kontrollierte Maßnahme**

Der Importprozess wurde nach Prüfung so angepasst, dass die Sperre kürzer gehalten wird.

**Verifikation**

```text
Antwortzeit:              300 bis 450 ms
Paketverlust:             weiterhin 0 %
Datenbanksperren:         keine auffällige Wartezeit
Import:                   weiterhin erfolgreich
```

---

**37. Beispiel „Dateiserver ist langsam“**

**Symptom**

Ein Benutzer erreicht beim Kopieren großer Dateien nur ungefähr 8 MB/s.

**Vergleich**

| Messung | betroffener Client | Referenzclient |
|---|---:|---:|
| Verbindung | 1 Gbit/s | 1 Gbit/s |
| Ping zum Server | 2 ms | 2 ms |
| `iperf3` | 920 Mbit/s | 925 Mbit/s |
| Dateiübertragung | 8 MB/s | 90 MB/s |
| lokale Datenträgerauslastung | 100 % | 15 % |

**Festgestellte Ursache**

Der lokale Zieldatenträger des betroffenen Clients war der Engpass. Die Netzwerkverbindung erreichte im kontrollierten Durchsatztest einen normalen Wert.

**Lehre**

```text
Ein langsamer Dateitransfer ist nicht automatisch ein langsames Netzwerk.
```

---

**38. Beispiel „WLAN ist langsam“**

**Symptom**

Benutzer in einem Besprechungsraum melden am Nachmittag langsame Anwendungen und Videokonferenzen.

**Vergleich**

```text
LAN:                         normal
WLAN außerhalb des Raums:    normal
WLAN im Besprechungsraum:    langsam
```

**Messwerte**

```text
Signalstärke:                ausreichend
Kanalauslastung:             sehr hoch
Retry-Rate:                  stark erhöht
aktive Clients:              42
AP-Uplink:                   unauffällig
```

**Festgestellte Ursache**

Der Funkkanal war stark ausgelastet. Viele erneute Übertragungen reduzierten den tatsächlichen Durchsatz.

**Kontrollierte Maßnahme**

Die Funkplanung wurde anhand der vorgesehenen WLAN-Managementfunktionen angepasst.

**Verifikation**

```text
Retry-Rate:                  deutlich reduziert
Anwendungsantwortzeit:       normal
Videokonferenzen:            stabil
```

---

**39. Ungeeignete Sofortmaßnahmen**

Nicht als erste Maßnahme verwenden:

- Server ohne vorherige Messung neu starten,
- Netzwerkgerät wahllos neu starten,
- DNS-Cache vor der Bestandsaufnahme löschen,
- alle Netzwerkadapter zurücksetzen,
- mehrere Kabel und Ports gleichzeitig wechseln,
- Sicherheitssoftware ohne Freigabe deaktivieren,
- VPN umgehen,
- Firewallregeln pauschal ändern,
- WLAN-Kanäle wahllos wechseln,
- unbegrenzten Paketmitschnitt starten,
- produktives Netzwerk unkontrolliert auslasten,
- Datenbankabfragen ungeprüft verändern,
- Serverressourcen ohne Messwerte erhöhen,
- Zeitüberschreitungen pauschal verlängern,
- aus einem einzelnen Ping eine Ursache ableiten,
- hohe Bandbreite mit hoher Anwendungsleistung gleichsetzen.

Solche Maßnahmen können Beweise vernichten, neue Fehler verursachen oder die eigentliche Ursache verdecken.

---

**40. Vollständige Prüfreihenfolge**

1. genaue Benutzeraktion erfassen.
2. erwartete und tatsächliche Dauer dokumentieren.
3. Startzeitpunkt, Häufigkeit und Dauer bestimmen.
4. betroffene Benutzer, Clients und Standorte erfassen.
5. LAN, WLAN und VPN unterscheiden.
6. einzelne Anwendung und allgemeines Systemverhalten vergleichen.
7. betroffenen Client mit Referenzclient vergleichen.
8. normalen Leistungsbereich als Baseline bestimmen.
9. lokale CPU-, Speicher- und Datenträgerauslastung prüfen.
10. Verbindungsgeschwindigkeit und Adapterstatus prüfen.
11. Gateway, internes Ziel und externes Ziel messen.
12. Latenz und Paketverlust getrennt betrachten.
13. Netzwerkpfad untersuchen.
14. TCP-Port prüfen.
15. DNS-Antwortzeit messen.
16. Anwendungsantwort in einzelne Zeitanteile zerlegen.
17. kontrollierten Durchsatztest durchführen.
18. Interface-Fehler, Drops und Retransmissions prüfen.
19. WLAN-Auslastung und Retry-Rate berücksichtigen.
20. VPN-Pfad und VPN-Gateway prüfen.
21. Server-CPU und Arbeitsspeicher überwachen.
22. Paging, Swapping und Ressourcenlimits prüfen.
23. Storage-Latenz und Warteschlangen untersuchen.
24. Datenbankabfragen, Sperren und Verbindungen prüfen.
25. APIs und externe Abhängigkeiten untersuchen.
26. alle Serverknoten einzeln vergleichen.
27. geplante Aufgaben und Hintergrundprozesse prüfen.
28. Messwerte auf einer gemeinsamen Zeitleiste darstellen.
29. größten Zeitanteil bestimmen.
30. Ursache und Folge unterscheiden.
31. genau eine messbare Hypothese formulieren.
32. Ausgangszustand und Rollback dokumentieren.
33. genau eine freigegebene Änderung durchführen.
34. ursprüngliche Messung wiederholen.
35. ausreichend lange Verifikation durchführen.
36. Nebenwirkungen kontrollieren.
37. temporäre Diagnosemaßnahmen entfernen.
38. Ursache, Maßnahme und Nachweis dokumentieren.

---

**41. Checkliste „Netzwerk oder Anwendung ist langsam“**

- [ ] genaue Benutzeraktion wurde dokumentiert.
- [ ] erwartete Dauer wurde erfasst.
- [ ] tatsächliche Dauer wurde gemessen.
- [ ] Zeitpunkt und Häufigkeit wurden dokumentiert.
- [ ] betroffene Benutzer wurden bestimmt.
- [ ] betroffene Clients wurden bestimmt.
- [ ] betroffene Standorte wurden bestimmt.
- [ ] LAN, WLAN und VPN wurden unterschieden.
- [ ] interner und externer Zugriff wurden verglichen.
- [ ] betroffener Client wurde mit einer Referenz verglichen.
- [ ] Baseline wurde bestimmt.
- [ ] lokale CPU-Auslastung wurde geprüft.
- [ ] lokaler Arbeitsspeicher wurde geprüft.
- [ ] lokaler Datenträger wurde geprüft.
- [ ] Hintergrundprozesse wurden geprüft.
- [ ] Verbindungsgeschwindigkeit wurde geprüft.
- [ ] Adapterstatistiken wurden geprüft.
- [ ] Gateway-Latenz wurde gemessen.
- [ ] Server-Latenz wurde gemessen.
- [ ] Paketverlust wurde geprüft.
- [ ] Netzwerkpfad wurde untersucht.
- [ ] TCP-Port wurde geprüft.
- [ ] DNS-Antwortzeit wurde gemessen.
- [ ] Zeit bis zum ersten Byte wurde gemessen.
- [ ] tatsächlicher Durchsatz wurde geprüft.
- [ ] beide Übertragungsrichtungen wurden berücksichtigt.
- [ ] Interface-Fehler wurden geprüft.
- [ ] Drops und Discards wurden geprüft.
- [ ] TCP-Retransmissions wurden berücksichtigt.
- [ ] WLAN-Kanalauslastung wurde geprüft.
- [ ] WLAN-Retry-Rate wurde geprüft.
- [ ] VPN-Verbindung wurde berücksichtigt.
- [ ] Server-CPU wurde überwacht.
- [ ] Serverarbeitsspeicher wurde überwacht.
- [ ] Paging oder Swapping wurde geprüft.
- [ ] Storage-Latenz wurde gemessen.
- [ ] Datenträgerwarteschlangen wurden berücksichtigt.
- [ ] Datenbankabfragen wurden geprüft.
- [ ] Datenbanksperren wurden berücksichtigt.
- [ ] APIs und externe Abhängigkeiten wurden geprüft.
- [ ] alle Serverknoten wurden verglichen.
- [ ] Backups und Snapshots wurden berücksichtigt.
- [ ] Virenscans und Updates wurden berücksichtigt.
- [ ] gemeinsame Zeitleiste wurde erstellt.
- [ ] größter Zeitanteil wurde bestimmt.
- [ ] Ursache und Folge wurden unterschieden.
- [ ] messbare Hypothese wurde formuliert.
- [ ] Ausgangszustand wurde dokumentiert.
- [ ] Rollback wurde festgelegt.
- [ ] nur eine kontrollierte Änderung wurde durchgeführt.
- [ ] Messungen wurden anschließend wiederholt.
- [ ] ausreichend lange Verifikation wurde durchgeführt.
- [ ] Nebenwirkungen wurden geprüft.
- [ ] Ursache und Nachweis wurden dokumentiert.

---

**42. Schnellreferenz**

| Beobachtung | Nächster Prüfbereich |
|---|---|
| nur ein Client langsam | Client, Treiber, Datenträger oder lokale Software |
| alle Clients langsam | gemeinsame Infrastruktur, Server oder Anwendung |
| Gateway bereits langsam | lokaler Zugang, WLAN, Kabel oder Switch |
| Gateway normal, Server langsam | interner Pfad, Servernetz oder Server |
| Ping normal, Anwendung langsam | Anwendung, Datenbank, API oder Storage |
| DNS langsam | DNS-Server, Weiterleitung oder Namensauflösung |
| TCP-Aufbau langsam | Netzwerkpfad, Firewall oder Zielsystem |
| erstes Byte langsam | Server, Anwendung oder Datenbank |
| Download nach erstem Byte langsam | Durchsatz, Paketverlust oder Datenmenge |
| `iperf3` schnell, Dateiübertragung langsam | Datenträger, Dateisystem, Virenscanner oder Protokoll |
| CRC-/FCS-Fehler steigen | Kabel, Stecker, Port oder Transceiver |
| Output Drops steigen | Auslastung oder nachgelagerter Engpass |
| nur WLAN langsam | Funkkanal, Retry-Rate, Roaming oder Access Point |
| nur VPN langsam | Internetpfad, VPN-Gateway, MTU oder Verschlüsselung |
| nur ein Serverknoten langsam | Konfiguration oder Ressource dieses Knotens |
| CPU dauerhaft hoch | Prozess, Last oder unzureichende Rechenleistung |
| CPU unauffällig, Storage-Latenz hoch | Storage, Backup, Snapshot oder Datenträger |
| Speicherdruck und Paging | Arbeitsspeicher, Prozess oder Ressourcenlimit |
| Anwendung während Backup langsam | Storage-, Netzwerk- und CPU-Auslastung vergleichen |
| Fehler nur bei großen Datenmengen | Durchsatz, Paketverlust, Storage oder Zeitlimit |
| Fehler nur bei vielen kleinen Dateien | IOPS, Dateisystem und Virenscanner |
| Monitoring zeigt nichts | Messintervall, Maximum und kurzfristige Spitzen prüfen |

---

**Merksatz**

> „Langsam“ ist zunächst nur ein Symptom. Erst durch den Vergleich von Latenz, Paketverlust, Durchsatz, Anwendungsantwortzeit, Serverressourcen, Storage und Datenbankwartezeiten lässt sich bestimmen, an welcher Stelle die tatsächliche Verzögerung entsteht.

---

**Quellen und weiterführende Dokumentation**

- [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn – Get-NetAdapter](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter)
- [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics)
- [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname)
- [Microsoft Learn – netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan)
- [Microsoft Learn – Windows Performance Monitor](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon)
- [curl – Write-Out Variables](https://curl.se/docs/manpage.html#-w)
- [iperf3 – Documentation](https://software.es.net/iperf/)
- [Wireshark – User’s Guide](https://www.wireshark.org/docs/wsug_html/)
- [Wireshark – TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html)
- [Wireshark – dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html)
- [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html)