Giriş
Web siteniz yavaşsa çoğu kişi ilk olarak şunu düşünür:
- CPU yetersiz
- Hosting kötü
- Tema ağır
- Plugin fazla
Ama gerçek çoğu zaman farklıdır:
Web sitelerinin büyük kısmı CPU yüzünden değil, veritabanı beklediği için yavaştır.
Ve daha kritik gerçek:
Veritabanı performansını en çok etkileyen şey yazılım değil, hosting altyapısıdır.
Bu yazıda:
- Database darboğazını nasıl anlarsınız
- Hosting veritabanını nasıl etkiler
- Nerede tıkanma olur
- Ne zaman upgrade gerekir
tam teknik olarak anlatacağız.
1. Site Neden Yavaş? CPU mu, Database mi?
Bir sayfa açılırken şu akış gerçekleşir:
Tarayıcı → Web Server → PHP → Database → PHP → HTML → Tarayıcı
Dinamik sitelerde (WordPress, WooCommerce, LMS, üyelik sistemleri):
- Her sayfa için onlarca query çalışır
- Database sürekli cevap üretir
Gerçek:
Sayfa yüklenme süresinin %60–80’i database beklemekle geçebilir.
2. Database Performansı Nasıl Ölçülür?
Veritabanı performansı tahmin edilmez → ölçülür.
| Metrik | İyi Değer |
|---|---|
| Query süresi | < 50 ms |
| Slow query | > 200 ms |
| Çok yavaş query | > 1 sn |
| DB response | < 100 ms |
| Disk latency | < 5 ms |
Eğer:
- Query süreleri yüksekse
- Disk latency yüksekse
sorun büyük ihtimalle hosting altyapısıdır.
3. En Büyük Darboğaz: Disk I/O
Veritabanı sürekli veri okur/yazar:
- Satır okur
- Index okur
- Log yazar
Bu yüzden en kritik faktör:
Disk hızı (I/O)
| Disk | IOPS |
|---|---|
| HDD | ~100 |
| SSD | ~5,000 |
| NVMe | 50,000+ |
Query süresi farkı:
| Disk | Query Süresi |
|---|---|
| HDD | 200–500 ms |
| SSD | 50–150 ms |
| NVMe | 5–30 ms |
Ana mesaj:
Yavaş veritabanının en yaygın sebebi yavaş disktir.
4. RAM ve InnoDB Buffer Pool
Database her şeyi diskten okumaz → RAM kullanır.
RAM = Database cache
Eğer RAM yeterliyse:
- Query hızlı
- Disk kullanımı düşük
Eğer RAM yetersizse:
- Sürekli disk erişimi
- Yavaş site
Öneri:
| DB Boyutu | RAM |
|---|---|
| 1 GB | 2 GB |
| 5 GB | 8 GB |
| 10 GB | 16 GB |
| 20 GB | 32 GB |
Yeterli RAM yoksa en hızlı NVMe disk bile tek başına yeterli olmaz.
5. CPU Ne Zaman Önemli?
CPU sadece şu durumlarda kritik:
- Ağır sorgular
- Çok join
- Raporlama
- Yüksek trafik
Ama çoğu site için:
Darboğaz = Disk + RAM
6. Hosting Türü Performansı Nasıl Etkiler?
| Özellik | Shared | VPS | Dedicated |
|---|---|---|---|
| Disk | Paylaşımlı | Ayrılmış | Size özel |
| RAM | Paylaşımlı | Ayrılmış | Size özel |
| CPU | Paylaşımlı | Ayrılmış | Size özel |
| DB performansı | Düşük | Orta | Çok yüksek |
Ana problem:
Shared hosting = paylaşılan disk → yavaş database
7. NVMe vs SSD
| Disk | IOPS |
|---|---|
| HDD | 100 |
| SSD | 5,000 |
| NVMe | 50,000+ |
Sonuç:
NVMe = En büyük veritabanı performans artışı
8. Object Cache (Redis / Memcached)
Mantık:
Normal: PHP → Database
Cache: PHP → RAM (Redis)
Sonuç:
| Durum | Query |
|---|---|
| Cache yok | 100 |
| Cache var | 30 |
| Full cache | 5–10 |
Özellikle:
- WooCommerce
- Üyelik sistemleri
- LMS
- Büyük bloglar
için object cache neredeyse zorunludur.
9. Slow Query Tespiti
Sorunu ayırmak gerekir:
| Belirti | Sebep |
|---|---|
| Her yer yavaş | Hosting |
| Bazı sayfalar yavaş | Query |
| Admin yavaş | Database |
| Checkout yavaş | Database |
Araçlar:
- Slow query log
- Query Monitor
- New Relic
10. Database Sunucu Konumu
Yanlış mimari:
Web server (EU) → Database (US)
Sonuç:
Her query = network latency → sayfa yavaş
Web server ile database aynı lokasyonda olmalıdır.
11. Ayrı Database Sunucusu Ne Zaman?
Gerekli durumlar:
- WooCommerce
- Membership
- LMS
- SaaS
- Yüksek trafik
- Büyük veritabanı
12. Hosting Sağlayıcısına Sorulacak Sorular
Hosting alırken şunları sorun:
- Diskler NVMe mi?
- Disk IOPS limiti var mı?
- Database için ne kadar RAM ayrılıyor?
- Redis / Memcached var mı?
- Aynı sunucuda kaç site var?
- Database ayrı sunucuda mı?
- Slow query log erişimi var mı?
- Günlük backup var mı?
- Database replication var mı?
Bu sorular hosting kalitesini gösterir.
13. Teknik Checklist
| Kontrol | İyi Durum |
|---|---|
| Query süresi | < 50 ms |
| Slow query | Yok |
| Disk | NVMe |
| RAM | Yeterli |
| Object cache | Var |
| DB server | Aynı lokasyon |
| CPU | %70 altı |
| Disk latency | < 5 ms |
14. Karar Ağacı – Database Darboğazı Var mı?
Aşağıdaki belirtilerden kaç tanesi sizde var?
| Belirti |
|---|
| Admin panel yavaş |
| Sepet / checkout yavaş |
| Filtreleme yavaş |
| Trafik artınca site yavaş |
| CPU düşük ama site yavaş |
| TTFB yüksek |
| Bazı sayfalar çok yavaş |
| Çok fazla plugin |
Eğer 3 veya daha fazla belirti varsa:
Database darboğazı var.
15. Sorun Nerede? (Kök Neden Analizi)
Disk Problemi
| Belirti | Sebep |
|---|---|
| Tüm site yavaş | Disk I/O |
| Rastgele yavaşlama | Paylaşımlı disk |
| Yoğun saatlerde yavaş | Shared hosting |
Çözüm: NVMe diskli hosting
RAM Yetersiz
| Belirti | Sebep |
|---|---|
| Trafik artınca yavaş | Cache doluyor |
| Query süreleri dalgalı | Buffer pool yetersiz |
Çözüm: Daha fazla RAM
Query Problemi
| Belirti | Sebep |
|---|---|
| Sadece bazı sayfalar yavaş | Kötü query |
| Admin panel çok yavaş | Plugin query |
| Belirli işlemler yavaş | Index yok |
Çözüm: Query optimize / index
Cache Yok
| Belirti | Sebep |
|---|---|
| Çok query var | Cache yok |
| Aynı sayfa sürekli DB’e gidiyor | Cache yok |
Çözüm: Redis / Memcached
Sunucu Konumu
| Belirti | Sebep |
|---|---|
| TTFB yüksek | Network latency |
| DB response yavaş | Uzak server |
Çözüm: DB ve web server aynı lokasyon
16. Hangi Seviyede Hosting Gerekli?
Seviye 1 – Küçük Siteler
- Shared hosting
- SSD
- Basic cache
Seviye 2 – Orta Siteler
- VPS
- NVMe
- Redis
- Yeterli RAM
Seviye 3 – Büyük Siteler
- Dedicated veya güçlü VPS
- NVMe yüksek IOPS
- Redis
- Ayrı database server
17. En Doğru Mimari
Web Server
+ PHP
+ Redis Cache
+ NVMe Disk
+ Yeterli RAM
+ Database Server
+ CDN
18. Final Sonuç
Bu yazının özeti:
Database performansı = Site performansı
Ve:
Hosting altyapısı güçlü değilse, yazılım optimizasyonu tek başına yeterli değildir.