Einleitung
Wenn Ihre Website langsam ist, denken die meisten zunächst:
- Unzureichende CPU
- Schlechtes Hosting
- Schweres Theme
- Zu viele Plugins
Doch die Realität sieht oft anders aus:
Der GroĂźteil der Websites ist nicht wegen der CPU langsam, sondern weil er auf die Datenbank wartet.
Und eine noch kritischere Wahrheit:
Was die Datenbankperformance am stärksten beeinflusst, ist nicht die Software, sondern die Hosting-Infrastruktur.
In diesem Artikel erklären wir technisch fundiert:
- Wie man einen Datenbankflaschenhals erkennt
- Wie Hosting die Datenbank beeinflusst
- Wo Flaschenhälse entstehen
- Wann ein Upgrade erforderlich ist
1. Warum ist die Website langsam? CPU oder Datenbank?
Beim Laden einer Seite findet folgender Ablauf statt:
Browser → Webserver → PHP → Datenbank → PHP → HTML → BrowserBei dynamischen Websites (WordPress, WooCommerce, LMS, Membership-Systeme):
- FĂĽr jede Seite werden Dutzende von Queries ausgefĂĽhrt
- Die Datenbank generiert kontinuierlich Antworten
Realität:
60–80 % der Seitenladezeit können mit dem Warten auf die Datenbank verbracht werden.
2. Wie wird Datenbankperformance gemessen?
Datenbankperformance wird nicht geschätzt — sie wird gemessen.
| Metrik | Guter Wert |
|---|---|
| Query-Zeit | < 50 ms |
| Slow Query | > 200 ms |
| Sehr langsame Query | > 1 s |
| DB-Response | < 100 ms |
| Disk-Latenz | < 5 ms |
Wenn:
- Query-Zeiten hoch sind
- Disk-Latenz hoch ist
liegt das Problem höchstwahrscheinlich an der Hosting-Infrastruktur.
3. Der größte Flaschenhals: Disk I/O
Die Datenbank liest und schreibt ständig Daten:
- Liest Zeilen
- Liest Indizes
- Schreibt Logs
Deshalb ist der kritischste Faktor:
Festplattengeschwindigkeit (I/O)
| Festplatte | IOPS |
|---|---|
| HDD | ~100 |
| SSD | ~5.000 |
| NVMe | 50.000+ |
Unterschiede in der Query-Zeit:
| Festplatte | Query-Zeit |
|---|---|
| HDD | 200–500 ms |
| SSD | 50–150 ms |
| NVMe | 5–30 ms |
Kernbotschaft:
Die häufigste Ursache für eine langsame Datenbank ist eine langsame Festplatte.
4. RAM und InnoDB Buffer Pool
Die Datenbank liest nicht alles von der Festplatte — sie nutzt RAM.
RAM = Datenbank-Cache
Wenn RAM ausreichend vorhanden ist:
- Queries sind schnell
- Festplattennutzung ist gering
Wenn RAM unzureichend ist:
- Ständige Festplattenzugriffe
- Langsame Website
Empfehlung:
| DB-Größe | RAM |
|---|---|
| 1 GB | 2 GB |
| 5 GB | 8 GB |
| 10 GB | 16 GB |
| 20 GB | 32 GB |
Ohne ausreichend RAM reicht selbst die schnellste NVMe-Festplatte allein nicht aus.
5. Wann ist die CPU wichtig?
Die CPU ist nur in folgenden Situationen kritisch:
- Aufwendige Queries
- Viele Joins
- Reporting
- Hoher Traffic
FĂĽr die meisten Websites gilt jedoch:
Flaschenhals = Festplatte + RAM
6. Wie beeinflusst der Hosting-Typ die Performance?
| Merkmal | Shared | VPS | Dedicated |
|---|---|---|---|
| Festplatte | Geteilt | Dediziert | Nur fĂĽr Sie |
| RAM | Geteilt | Dediziert | Nur fĂĽr Sie |
| CPU | Geteilt | Dediziert | Nur fĂĽr Sie |
| DB-Performance | Niedrig | Mittel | Sehr hoch |
Kernproblem:
Shared Hosting = geteilte Festplatte → langsame Datenbank
7. NVMe vs. SSD
| Festplatte | IOPS |
|---|---|
| HDD | 100 |
| SSD | 5.000 |
| NVMe | 50.000+ |
Fazit:
NVMe = Größte Leistungssteigerung für die Datenbank
8. Object Cache (Redis / Memcached)
Prinzip:
Normal: PHP → Datenbank
Cache: PHP → RAM (Redis)Ergebnis:
| Zustand | Queries |
|---|---|
| Kein Cache | 100 |
| Cache aktiv | 30 |
| Voller Cache | 5–10 |
Besonders fĂĽr:
- WooCommerce
- Membership-Systeme
- LMS
- GroĂźe Blogs
ist Object Cache nahezu unverzichtbar.
9. Erkennung von Slow Queries
Das Problem muss isoliert werden:
| Symptom | Ursache |
|---|---|
| Alles ist langsam | Hosting |
| Einige Seiten sind langsam | Query |
| Admin-Panel ist langsam | Datenbank |
| Checkout ist langsam | Datenbank |
Werkzeuge:
- Slow Query Log
- Query Monitor
- New Relic
10. Datenbankserver-Standort
Falsche Architektur:
Webserver (EU) → Datenbank (US)Ergebnis:
Jede Query = Netzwerklatenz → langsame SeiteWebserver und Datenbank müssen sich am selben Standort befinden.
11. Wann ist ein separater Datenbankserver nötig?
Erforderliche Situationen:
- WooCommerce
- Membership
- LMS
- SaaS
- Hoher Traffic
- GroĂźe Datenbank
12. Fragen an Ihren Hosting-Anbieter
Stellen Sie beim Kauf von Hosting folgende Fragen:
- Sind die Festplatten NVMe?
- Gibt es ein Disk-IOPS-Limit?
- Wie viel RAM wird fĂĽr die Datenbank reserviert?
- Ist Redis / Memcached verfĂĽgbar?
- Wie viele Websites befinden sich auf demselben Server?
- Liegt die Datenbank auf einem separaten Server?
- Gibt es Zugriff auf Slow Query Logs?
- Gibt es tägliche Backups?
- Gibt es Datenbankreplikation?
Diese Fragen zeigen die Qualität des Hostings.
13. Technische Checkliste
| PrĂĽfpunkt | Guter Zustand |
|---|---|
| Query-Zeit | < 50 ms |
| Slow Query | Keine |
| Festplatte | NVMe |
| RAM | Ausreichend |
| Object Cache | Vorhanden |
| DB-Server | Gleicher Standort |
| CPU | Unter 70 % |
| Disk-Latenz | < 5 ms |
14. Entscheidungsbaum – Gibt es einen Datenbankflaschenhals?
Wie viele der folgenden Symptome treffen auf Sie zu?
| Symptom |
|---|
| Admin-Panel ist langsam |
| Warenkorb / Checkout ist langsam |
| Filterung ist langsam |
| Website verlangsamt sich bei mehr Traffic |
| CPU ist niedrig, aber Website ist langsam |
| TTFB ist hoch |
| Einige Seiten sind sehr langsam |
| Sehr viele Plugins |
Wenn 3 oder mehr Symptome zutreffen:
Es liegt ein Datenbankflaschenhals vor.
15. Wo liegt das Problem? (Ursachenanalyse)
Festplattenproblem
| Symptom | Ursache |
|---|---|
| Gesamte Website langsam | Disk I/O |
| Zufällige Verlangsamungen | Geteilte Festplatte |
| Langsam zu StoĂźzeiten | Shared Hosting |
Lösung: Hosting mit NVMe-Festplatten
Unzureichender RAM
| Symptom | Ursache |
|---|---|
| Langsam bei steigendem Traffic | Cache fĂĽllt sich |
| Schwankende Query-Zeiten | Unzureichender Buffer Pool |
Lösung: Mehr RAM
Query-Problem
| Symptom | Ursache |
|---|---|
| Nur bestimmte Seiten langsam | Schlechte Query |
| Admin-Panel sehr langsam | Plugin-Query |
| Bestimmte Operationen langsam | Kein Index |
Lösung: Query-Optimierung / Index
Kein Cache
| Symptom | Ursache |
|---|---|
| Zu viele Queries | Kein Cache |
| Dieselbe Seite greift immer auf die DB zu | Kein Cache |
Lösung: Redis / Memcached
Serverstandort
| Symptom | Ursache |
|---|---|
| TTFB ist hoch | Netzwerklatenz |
| DB-Response ist langsam | Entfernter Server |
Lösung: DB und Webserver am gleichen Standort
16. Welches Hosting-Niveau ist erforderlich?
Stufe 1 – Kleine Websites
- Shared Hosting
- SSD
- Einfaches Caching
Stufe 2 – Mittlere Websites
- VPS
- NVMe
- Redis
- Ausreichend RAM
Stufe 3 – Große Websites
- Dedicated oder leistungsstarker VPS
- NVMe mit hohem IOPS
- Redis
- Separater Datenbankserver
17. Die optimale Architektur
Webserver
+ PHP
+ Redis Cache
+ NVMe-Festplatte
+ Ausreichend RAM
+ Datenbankserver
+ CDN18. AbschlieĂźendes Fazit
Die Zusammenfassung dieses Artikels:
Datenbankperformance = Website-Performance
Und:
Wenn die Hosting-Infrastruktur nicht leistungsstark ist, reicht Software-Optimierung allein nicht aus.