Hızlı Özet
17.36
Load Average
(72 çekirdek sunucu)
54
lsphp Process
Çoğu %100 CPU
241
Redis Clients
Aktif bağlantı
80-120ms
Ping Süresi
Sunucu tarafından
Tespit Edilen Yavaşlık Sebepleri
Route ve Config Cache YOK!
KRİTİKbootstrap/cache/ içeriği:
modules.php ✓ packages.php ✓ services.php ✓ config.php ✗ YOK! routes.php ✗ YOK!
Cache yokken:
- Her request'te tüm route dosyaları parse edilir
- Her request'te tüm config dosyaları okunur
- Modül route'ları tek tek yüklenir
Cache varken:
- Tek dosyadan tüm route'lar yüklenir
- Tek dosyadan tüm config yüklenir
- ~30-50ms tasarruf
Çözüm: php artisan config:cache && php artisan route:cache
Ping Route'a Çok Fazla Middleware
YÜKSEK ETKİ
Basit bir /api/muzibu/ping isteği için çalışan middleware'ler:
// Global API Middleware Grubu (bootstrap/app.php) 1. EnsureFrontendRequestsAreStateful - Sanctum session kontrolü 2. InitializeTenancy - Database tenant switch! 3. SubstituteBindings - Route model binding 4. DatabasePoolMiddleware - Connection pooling 5. ResourceTrackingMiddleware - Sistem izleme! // Route-Specific 6. throttle:120,1 - Rate limiting = 6 middleware sadece {"pong": true} döndürmek için!
Not: Statik JSON bu middleware'leri bypass eder AMA gerçek API deneyimini yansıtmaz. Eşikleri güncellemek daha dürüst bir çözüm.
Yüksek CPU Kullanımı (lsphp)
PERFORMANStop - 16:29:24 up 36 days Load average: 17.36, 12.32, 10.71 PID USER %CPU COMMAND 2795609 tuufi.c+ 100.0 lsphp 2795584 tuufi.c+ 100.0 lsphp 2787971 tuufi.c+ 100.0 lsphp 2791507 tuufi.c+ 100.0 lsphp 2802518 tuufi.c+ 100.0 lsphp 2802749 tuufi.c+ 100.0 lsphp ... (54 lsphp process aktif)
54 PHP process'in çoğu %100 CPU kullanıyor. Bu yoğun trafik veya verimsiz kod işareti olabilir.
Yüksek Redis Client Sayısı
İZLEME241
Connected Clients
1305
ops/sec
446MB
Memory
2MB/s
Output
241 eşzamanlı Redis client normal trafik için yüksek. Connection pooling kontrol edilmeli.
OPcache Config Şüpheli
KONTROL GEREKLİ# /opt/plesk/php/8.3/etc/php.ini ;zend_extension=opcache ← Yorum satırı! [opcache] ;opcache.enable=1 ← Yorum satırı! ;opcache.enable_cli=0 ← Yorum satırı!
PHP config'de OPcache satırları yorum olarak görünüyor. Plesk üzerinden ayrı aktif edilmiş olabilir, ama doğrulanması gerekiyor.
"Gecikme" Tam Olarak Ne Ölçüyor?
| Bileşen | Süre | Açıklama | Kontrol |
|---|---|---|---|
| DNS Çözümleme | ~2ms | Domain → IP dönüşümü | ✓ Normal |
| TCP Bağlantı | ~7ms | Üçlü el sıkışma | ✓ Normal |
| SSL/TLS | ~23ms | HTTPS şifreleme | ○ Kabul edilebilir |
| Laravel İşleme | ~40-60ms | Middleware + Route + Response | ✗ Yüksek! |
| Kullanıcı Network | 20-100ms | ISP ve mesafe | ↔ Değişken |
| TOPLAM | 90-190ms | En iyi durumda bile! |
Önemli: Gecikme testi Laravel üzerinden yapıldığı için gerçek kullanıcı deneyimini yansıtıyor. Eğer statik dosya ile test etsek, test sonucu iyi görünür ama kullanıcı gerçekte yavaşlık yaşamaya devam eder. Bu yüzden eşikleri güncellemek daha dürüst bir çözüm.
Önerilen Eşik Güncellemeleri
Laravel tabanlı bir sistem için mevcut eşikler gerçekçi değil. Aşağıdaki güncellemeler önerilir:
| Kategori | Mevcut | Önerilen | Neden? |
|---|---|---|---|
| Mükemmel (Yeşil) | ≤50ms |
≤150ms |
Sunucu 80ms, +network ile 150ms makul |
| İyi (Açık Yeşil) | ≤100ms |
≤250ms |
Çoğu fiber kullanıcı burada olmalı |
| Normal (Sarı) | ≤200ms |
≤400ms |
Mobil ve orta hızlı bağlantılar |
| Kötü (Kırmızı) | >200ms |
>400ms |
Gerçekten sorunlu bağlantılar |
Görsel Karşılaştırma
Mevcut Eşikler
Önerilen Eşikler
Sonuç ve Öneriler
Hemen Yapılabilir (Düşük Risk)
- Gecikme eşiklerini güncelle (alpine-apps.js)
- Bar formülünü daha adil yap
Bakım Penceresi Gerektirir
- Route cache ve config cache aktifle
- OPcache durumunu doğrula
- lsphp process yükünü araştır
Not: Bu rapor sadece araştırma içerir, hiçbir değişiklik yapılmamıştır. Değişiklikler için onay verildiğinde uygulanabilir.