Ana Sayfa Sunucu Engelleme Analizi

Sunucu Tarafı Engelleme Analizi

Hangi Sunucu İşlemleri Player'ı Bekletiyor?

Player şarkı çalmaya başlamadan önce sunucudan bazı bilgileri almak zorundadır. Bu bilgiler sırayla istenir ve her biri bir öncekinin bitmesini bekler. Yavaş internette bu zincir 3-8 saniyeye kadar uzar ve kullanıcı "donma" yaşar. Bu rapor, hangi sunucu işlemlerinin player'ı bloke ettiğini ve hangilerinin arka planda sessizce çalıştığını gösterir.

1. Player'ı Bloke Eden vs Etmeyen İşlemler

Sunucu işlemlerini iki gruba ayırdık: Player'ın çalmak için cevabını zorunlu olarak beklediği istekler ve arka planda sessizce çalışan istekler.

Player'ı Bekletenler

Bunlar bitmeden ses çıkmaz

1

/stream — Premium Kontrolü

Kullanıcının aboneliği var mı? Her seferinde veritabanına taze sorgu atıyor. Cache kullanmıyor.

20-500 ms gecikme

2

/hls-key — Şifreleme Anahtarı

Şarkı şifresini çözmek için gereken anahtar dosyası diskten okunuyor.

10-50 ms gecikme

3

/hls/master.m3u8 — Playlist İşleme

HLS playlist dosyası okunup, URL'lere imza parametreleri ekleniyor (regex ile).

30-100 ms gecikme

Toplam: 60-650 ms bekleme (yavaş internette 3-8 sn)

Arka Planda Çalışanlar

Bunlar donmaya sebep olmaz

track-start — Dinleme Kaydı

Şarkı zaten çalmaya başladıktan sonra gönderilir. Kullanıcı bunu fark etmez.

20-50 ms (ama şarkı çalıyor)

track-hit — 30 sn Sayaç

30 saniye sonra arka planda çalışır. Player'a hiçbir etkisi yok.

20-50 ms (30 sn sonra)

track-end — Bitiş Kaydı

sendBeacon ile "gönder ve unut" yöntemiyle çalışır. Player hiç beklemez.

0 ms bekleme (fire-and-forget)

popular() — Popüler Listesi

Redis'te 30 dakika cache'li. Hızlı yanıt verir.

5-20 ms (cache'li)

2. Seri Bekleme Zinciri — Donmanın Ana Sebebi

3 bloke eden istek birbirini bekleyerek sırayla çalışır. Biri bitmeden diğeri başlayamaz. Bu seri zincir, yavaş internette toplam beklemeyi katlar.

HLS Modu — Seri Zincir (Şu Anki Durum)

Her istek bir öncekinin cevabına bağlı. Paralel çalışamaz.

0 ms

"Çal" butonuna basıldı

Player sunucuya stream URL isteği gönderiyor

20 ms

bekle...

isPremium() — Veritabanı Sorgusu

Her şarkıda taze sorgu. "Bu kullanıcının aboneliği var mı?" diye DB'ye soruyor. Sonucu cache'lemiyor.

1 SELECT sorgusu 20-100 ms Cache YOK

200 ms

İmzalı URL üretimi (HMAC-SHA256)

Kontrol geçti → şifreli stream adresi üretiliyor. Bu hızlı (kripto işlem).

1-2 ms

250 ms

bekle...

Şifreleme Anahtarı İndirme

HLS şarkının şifresini çözmek için .key dosyası sunucu diskinden okunuyor (file_get_contents()).

Disk I/O 10-50 ms

400 ms

bekle...

HLS Playlist İşleme

master.m3u8 dosyası diskten okunuyor, içindeki URL'lere preg_replace() ile imza parametreleri ekleniyor.

Disk I/O + Regex 30-100 ms

600 ms

bekle...

İlk Segment İndirme + AES-128 Şifre Çözme

İlk ses parçası indirilip CPU'da şifresi çözülüyor. Eski cihazlarda bu adım en yavaş olanıdır.

CPU yoğun 100-400 ms

1000 ms

Ses Çıkıyor!

İyi internette ~1 sn. Yavaş internette 3-8 sn sessizlik ve donma.

MP3 Modu (Soft Mode) — Kısa Zincir

Key, playlist ve şifre çözme adımları tamamen ortadan kalkıyor. 4 adım yerine 2 adım.

0 ms

"Çal" butonuna basıldı → Stream URL isteği

20 ms

isPremium() — Tek kalan bekleme noktası

Bu da cache'lenirse ~5 ms'ye düşer

300 ms

Ses Çıkıyor!

Key yok, playlist yok, şifre çözme yok. Howler.js doğrudan MP3 çalmaya başlıyor.

HLS: 4-6 seri istek → 1-8 sn bekleme

MP3: 1 istek → 0.3-2 sn bekleme

%60-75 daha hızlı başlangıç

3. Her Endpoint'in Detaylı Analizi

isPremium() — Her Şarkıda Taze DB Sorgusu

EN YAVAŞ

SongStreamController.php, satır 82 → User model, satır 454-472

Şu An Ne Yapıyor?

  • Her şarkıda veritabanına gidip subscription_expires_at alanını soruyor
  • Daha önce sorguladığı sonucu cache'lemiyor
  • 10 şarkı dinlerse 10 kez aynı sorguyu tekrarlıyor
  • Her sorgu 20-100 ms (yavaş DB'de 200-500 ms)

Ne Yapılmalı?

  • Sonucu Redis'te 5 dakika cache'le
  • Abonelik durumu 5 dakikada değişmez
  • Cache hit: 20-100 ms → 1-2 ms
  • 10 şarkı = 10 × 100 ms = 1 sn tasarruf

serveKey() — Disk'ten Anahtar Okuma

ORTA

SongStreamController.php, satır 553-633

Şu An Ne Yapıyor?

  • file_get_contents() ile diskten .key dosyası okuyor
  • İmza doğrulaması yapıyor (HMAC-SHA256)
  • Disk I/O: 10-50 ms (yoğun saatlerde daha uzun)

Ne Yapılmalı?

  • Key binary'yi Redis'te cache'le (24 saat TTL)
  • Key dosyaları çok küçük (~16 byte) — Redis'te yer kaplamaz
  • Disk I/O → Redis: 10-50 ms → 1 ms

Soft Mode'da (MP3): Bu endpoint hiç çağrılmaz. Key dosyası sadece HLS şifreli akış için gereklidir. MP3'te şifreleme yok → bu gecikme tamamen ortadan kalkar.

serveHls() — Playlist Regex İşleme

ORTA

SongStreamController.php, satır 645-743

Şu An Ne Yapıyor?

  • Diskten .m3u8 playlist dosyasını okuyor
  • 2 adet preg_replace() ile URL'lere imza ekleniyor
  • 30-100 ms (büyük playlist'lerde daha uzun)

Ne Yapılmalı?

  • Playlist'leri önceden işleyip cache'le
  • Veya HLS convert sırasında imzalı URL'leri doğrudan göm

Soft Mode'da (MP3): Bu endpoint hiç çağrılmaz. MP3 tek dosyadır, playlist yoktur. Bu gecikme tamamen ortadan kalkar.

recent() — Son Dinlenenler (Cache'siz)

DÜŞÜK

SongController.php, satır 24-81

Şu An Ne Yapıyor?

  • Her çağrıda 2-3 fresh DB sorgusu
  • Redis cache yok (popular() var ama recent() yok)
  • 100-300 ms response süresi

Ne Yapılmalı?

  • Redis cache (5 dakika TTL)
  • 100-300 ms → 5-10 ms

Not: Bu endpoint şarkı çalmayı değil, liste yüklemeyi etkiler. Doğrudan donma yapmaz ama sayfa yüklenme hızını düşürür.

4. Çözüm Özeti

Sorun Şu An Cache Sonrası Soft Mode
isPremium() DB sorgusu 20-500 ms 1-2 ms (Redis) 1-2 ms (Redis)
Key disk okuma 10-50 ms 1 ms (Redis) Yok (MP3'te key yok)
Playlist regex 30-100 ms 5 ms (pre-process) Yok (MP3'te playlist yok)
Segment + şifre çözme 100-400 ms 100-400 ms (değişmez) Yok (MP3'te şifreleme yok)
recent() listesi 100-300 ms 5-10 ms (Redis) 5-10 ms (Redis)
TOPLAM BEKLEME 260-1350 ms 110-420 ms 5-15 ms

Şu An (HLS, cache yok)

1-8 sn

Yavaş internette bekleme

HLS + Cache Optimizasyonu

0.3-1 sn

Büyük iyileşme

Soft Mode (MP3)

0.3 sn

Neredeyse anında