Neden Herkes "Yavaş" Görünüyor?

System Check Sayfası - Tam Detaylı Analiz Raporu

5 Sorun Tespit Edildi 13 Şubat 2026 Sadece Araştırma (Değişiklik Yok)

"Gecikme" Tam Olarak Ne Demek?

Basit Anlatım (Herkes İçin)

Gecikme = Bir şey isteyip cevap almanın ne kadar sürdüğü.

Örnek düşün:

Sen

"Merhaba!" dersin

Yol

Sesin gidiyor

Sunucu

Duyuyor, düşünüyor

Cevap

"Merhaba!" geliyor

Sorun: Sunucu çok yavaş "düşünüyor"!

Sen ne kadar hızlı internet kullanırsan kullan, sunucu yavaşsa beklersin. Tıpkı hızlı koşsan bile karşındaki kişi yavaş cevap veriyorsa beklediğin gibi.

Teknik Detay (Geliştiriciler İçin)

System Check sayfasında "Gecikme" testi şu JavaScript koduyla yapılıyor: 

// alpine-apps.js satır 841-849
const latencies = [];
for (let i = 0; i < 5; i++) {
    const start = performance.now();
    await fetch('/api/muzibu/ping?t=' + Date.now(), {
        method: 'HEAD',
        cache: 'no-store'
    });
    latencies.push(performance.now() - start);
}
this.latencyMs = Math.round(latencies.reduce((a, b) => a + b, 0) / latencies.length);

Ne yapıyor?

  • • 5 kez /api/muzibu/ping endpoint'ine istek atıyor
  • • Her isteğin ne kadar sürdüğünü ölçüyor
  • • 5 ölçümün ortalamasını alıyor
  • • Sonucu "Gecikme" olarak gösteriyor

Bu süre neleri içeriyor?

  • • DNS çözümleme (~2ms)
  • • TCP bağlantı kurma (~7ms)
  • • SSL/TLS el sıkışma (~23ms)
  • • Laravel işleme (~40-60ms)
  • • Kullanıcı network gecikmesi (değişken)

Kritik Nokta:

/api/muzibu/ping bir Laravel route'u. Yani basit bir "pong" cevabı için bile Laravel'in tüm middleware zinciri çalışıyor. Bu da minimum 80-120ms demek - kullanıcının interneti ne kadar hızlı olursa olsun!

1

Route ve Config Cache YOK!

KRİTİK - EN BÜYÜK SORUN

Basit Anlatım

Bir restoran düşün:

Cache YOKKEN (Şu anki durum)

Her müşteri geldiğinde garson:

  • 📋 Menüyü baştan yazıyor
  • 📋 Fiyatları tek tek hesaplıyor
  • 📋 Malzemeleri sayıyor
  • ⏰ Her seferinde 30-50 saniye kaybediyor!

Cache VARKEN (Olması gereken)

Garson sabah bir kere hazırlık yapıyor:

  • ✅ Menü hazır, basılı
  • ✅ Fiyatlar belirli
  • ✅ Her şey düzenli
  • ⚡ Müşteriye anında hizmet!

Yani şu an olan:

Her kullanıcı siteye girdiğinde, sistem "hangi sayfalar var, ayarlar ne" diye baştan hesaplıyor. Bu gereksiz yere 30-50ms kaybettiriyor.

Teknik Detay

Laravel'de bootstrap/cache/ klasörü kontrol edildi: 

# ls -la bootstrap/cache/

modules.php   ✓ VAR  (4.4 KB)
packages.php  ✓ VAR  (6.5 KB)
services.php  ✓ VAR  (27.9 KB)

config.php    ✗ YOK!  ← Tüm config dosyaları her request'te okunuyor
routes.php    ✗ YOK!  ← Tüm route dosyaları her request'te parse ediliyor

Cache yokken ne oluyor?

  • • config/*.php → ~30 dosya okunuyor
  • • routes/*.php → ~10 dosya parse ediliyor
  • • Modules/*/routes/*.php → ~50+ dosya
  • • Her dosya için disk I/O + PHP parse
  • = Her request'te +30-50ms!

Cache varken ne oluyor?

  • • config.php → TEK dosya, serialize edilmiş
  • • routes.php → TEK dosya, derlenmiş
  • • Disk I/O minimal
  • • PHP parse yok, direkt yükleme
  • = ~5ms'de tamamlanır!

Çözüm Komutları (Bakım zamanı için): 

php artisan config:cache   # Config'i tek dosyaya derle
php artisan route:cache    # Route'ları tek dosyaya derle

⚠️ Not: Route cache aktifken Route::... içinde closure kullanamazsın, controller method'larına taşınmalı.

2

Basit Ping İçin 6 Middleware Çalışıyor!

YÜKSEK ETKİ

Basit Anlatım

Bir kapıdan geçmek istiyorsun:

1

Güvenlik 1: "Kim bu?"

Sanctum - Giriş yapmış mı kontrol ediyor

2

Güvenlik 2: "Hangi şirketten?"

Tenant - Hangi site olduğunu belirliyor (database değiştiriyor!)

3

Güvenlik 3: "Ne istiyor?"

SubstituteBindings - URL'deki ID'leri objelere çeviriyor

4

Güvenlik 4: "Veritabanı bağlantısı"

DatabasePool - Connection havuzunu yönetiyor

5

Güvenlik 5: "İstatistik tutalım"

ResourceTracking - Sistem kaynaklarını izliyor

6

Güvenlik 6: "Çok mu sık geliyor?"

Throttle - Rate limiting kontrolü

Sorun ne?

Sadece "pong" demek için 6 kapıdan geçiyoruz! Her kapı 5-10ms sürüyor. Toplamda 30-60ms sadece kapılar için!

Teknik Detay

/api/muzibu/ping route'una istek geldiğinde çalışan middleware zinciri: 

// bootstrap/app.php - API middleware grubu

$middleware->group('api', [
    \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
    \App\Http\Middleware\InitializeTenancy::class,  // ← DB switch!
    \Illuminate\Routing\Middleware\SubstituteBindings::class,
]);

// Ayrıca global olarak eklenen:
DatabasePoolMiddleware::class      // ← Connection pool
ResourceTrackingMiddleware::class  // ← İzleme

// Route-specific:
->middleware('throttle:120,1')  // ← Rate limiting

// Ping route'un kendisi:
Route::get('/ping', fn() => response()->json(['pong' => true]))

// Sonuç: {"pong": true} için 6 middleware + Laravel bootstrap!

Neden bu kadar middleware var?

Çünkü ping route'u /api/muzibu/ prefix'i altında. Bu prefix'e gelen TÜM istekler için bu middleware'ler çalışıyor. Ping endpoint'i ayrıcalıklı değil, normal bir API route'u gibi muamele görüyor.

3

54 PHP Process %100 CPU Kullanıyor!

PERFORMANS SORUNU

Basit Anlatım

Bir fabrika düşün:

Normal Durum

  • 👷 50 işçi var
  • 📊 Ortalama %30-50 meşgul
  • 😊 Yeni iş gelince hemen başlıyorlar
  • ✅ Sistem rahat çalışıyor

Şu Anki Durum

  • 👷 54 işçi var
  • 📊 Çoğu %100 meşgul!
  • 😰 Yeni iş gelince sıra bekliyor
  • ❌ Sistem zorlanıyor

Ne anlama geliyor?

Sunucuda 54 PHP işçisi (process) var ve çoğu son hızda çalışıyor. Yeni bir istek geldiğinde boş işçi bulmak zorlaşıyor, bu da bekleme süresi demek.

Teknik Detay

top komutunun çıktısı: 

top - 16:29:24 up 36 days
Load average: 17.36, 12.32, 10.71   ← 72 çekirdek için yüksek!
Tasks: 1051 total, 14 running

    PID USER       %CPU  COMMAND
2795609 tuufi.c+  100.0 lsphp    ← %100!
2795584 tuufi.c+  100.0 lsphp    ← %100!
2787971 tuufi.c+  100.0 lsphp    ← %100!
2791507 tuufi.c+  100.0 lsphp    ← %100!
2802518 tuufi.c+  100.0 lsphp    ← %100!
2802749 tuufi.c+  100.0 lsphp    ← %100!
... (toplam 54 lsphp process)

Sunucu CPU

72

çekirdek

Load Average

17.36

son 1 dakika

Aktif PHP

54

lsphp process

lsphp nedir?

lsphp = LiteSpeed PHP. Sunucu LiteSpeed web server kullanıyor ve her PHP isteği için bir lsphp process'i çalışıyor. Bu process'lerin çoğu %100 CPU kullanıyorsa, ya çok yoğun trafik var ya da PHP kodları verimsiz çalışıyor (örn: cache yok!).

4

241 Redis Client Bağlı

İZLENMELİ

Basit Anlatım

Redis = Süper hızlı not defteri

Redis, sık kullanılan bilgileri hafızada tutan bir sistem. Veritabanına gitmek yerine Redis'e bakıyoruz - çok daha hızlı!

Şu anki durum:

241

Bağlı kullanıcı

1305

İşlem/saniye

446MB

Kullanılan bellek

2MB/s

Veri çıkışı

241 bağlantı normal mi?

54 PHP process var ama 241 Redis bağlantısı var. Bu, her PHP process'in 4-5 Redis bağlantısı açtığı anlamına gelebilir. Connection pooling kontrol edilmeli.

Teknik Detay

# redis-cli INFO

connected_clients:241
used_memory_human:446.13M
instantaneous_ops_per_sec:1305
instantaneous_input_kbps:427.09
instantaneous_output_kbps:2037.82

Neden önemli?

Her Redis bağlantısı kaynak tüketir. 54 PHP process için 241 bağlantı demek, her process ortalama 4-5 bağlantı açıyor. Bu genellikle:

  • • Cache için bir bağlantı
  • • Session için bir bağlantı
  • • Queue için bir bağlantı
  • • Broadcasting için bir bağlantı

Persistent connection veya connection pooling ile azaltılabilir.

5

OPcache Durumu Şüpheli

KONTROL GEREKLİ

Basit Anlatım

OPcache = PHP'nin "ezberlemesi"

OPcache KAPALI

Her istek geldiğinde:

  • 📖 PHP dosyasını oku
  • 🔍 Kodu analiz et (parse)
  • ⚙️ Makine diline çevir (compile)
  • ▶️ Sonra çalıştır
  • = Her seferinde aynı iş!

OPcache AÇIK

İlk seferde:

  • 📖 PHP dosyasını oku
  • ⚙️ Derle ve HAFIZADA TUT
  • 💾 Sonraki isteklerde direkt çalıştır
  • = Çok daha hızlı!

Neden şüpheli?

PHP config dosyasında OPcache satırları yorum satırı olarak görünüyor (başında ; var). Ama Plesk üzerinden ayrı aktif edilmiş olabilir. Kesin doğrulama gerekiyor.

Teknik Detay

# /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ı!
;opcache.memory_consumption=128
;opcache.interned_strings_buffer=8
;opcache.max_accelerated_files=10000

Doğrulama gerekiyor:

Plesk, PHP ayarlarını farklı bir yerde override edebilir. phpinfo() veya php -i | grep opcache ile gerçek durumu kontrol etmek gerekiyor.

Sonuç: Ne Yapılmalı?

# Sorun Etki Çözüm Risk
1 Route/Config Cache Yok +30-50ms config:cache, route:cache Orta
2 Çok Middleware +30-60ms Eşikleri güncelle (dürüst çözüm) Düşük
3 Yüksek CPU (lsphp) Genel yavaşlık Cache aktifle, kodu optimize et Orta
4 241 Redis Client Kaynak tüketimi Persistent connection kontrol et İzle
5 OPcache Şüpheli ? phpinfo() ile doğrula Kontrol

Hemen Yapılabilir (Düşük Risk)

  • Gecikme eşiklerini gerçekçi yap (150/250/400ms)
  • Bar gösterim formülünü güncelle

Bu değişiklikler sadece görsel - backend'e dokunmuyor.

Bakım Gerektirir

  • Route ve config cache aktifle
  • OPcache durumunu doğrula ve aktifle
  • Redis connection pooling incele

Bu değişiklikler sunucuyu etkiler - bakım penceresi gerekir.

Not: Bu rapor sadece araştırma içerir. Hiçbir değişiklik yapılmamıştır. Tüm sistemler olduğu gibi çalışmaya devam ediyor.