Cloudflare, Workers için talep üzerine CPU ve bellek flamegraph profilleme özelliğini ekledi

Talep üzerine profilleme yayında

Cloudflare, Workers ve Durable Objects için talep üzerine CPU ve bellek profilleme özelliğini ekledi; sonuçlar etkileşimli flamegraph olarak görüntüleniyor. Cloudflare bloguna göre geliştiriciler, dashboard'daki Observability sayfasından canlı bir Worker'ın profilini talep edebilir, bunu flamegraph olarak görüntüleyebilir ve daha derin çevrimdışı analiz için profil dosyasını indirebilir.

Profil yakalamanın iki yolu

İki giriş noktası var. Dashboard'da Build, ardından Compute, sonra Workers & Pages bölümüne gidip Worker'ınızı seçerek Observability sekmesini açın; buradaki Flamegraph etiketli açılır menü hem CPU hem de bellek profilleri sunuyor. Alternatif olarak, cf paketi kuruluysa tek bir komut beş saniyelik bir CPU profilini dosyaya kaydeder:

cf workers versions profile latest
--worker-id "$WORKER_ID_OR_NAME"
--duration-ms 5000
--profile-type cpu > worker-cpu.pprof

Süre ayarı profiler'ın ne kadar süre çalışacağını kontrol ediyor ve hedefleyeceğiniz Worker sürümünü seçebilirsiniz. Cloudflare, yakalamanın başarılı olması için Worker'ın sağlıklı miktarda trafik alması gerektiği konusunda uyarıyor; dolayısıyla sessiz sürümler iyi adaylar değil.

Sonuçları okumak

Flamegraph'taki her bir dikdörtgen bir fonksiyon çağrısını temsil eder; genişliği o fonksiyonun ne kadar CPU süresi veya bellek tükettiğini gösterir. Bir fonksiyona tıklamak görünümü odaklar, üzerine gelmek ayrıntıları gösterir ve bir tablo görünümü örnekte en sık görülen fonksiyonları sıralar. Cloudflare'nin tavsiyesi birkaç profil alıp en geniş kutuları avlamaktır. Dikkat edilmesi gereken bir nokta: TypeScript projeleri source map'leri etkinleştirmeli, aksi halde flamegraph karışık (obfuscate edilmiş) fonksiyon adları gösterecektir.

İki dahili vaka çalışması

Cloudflare, birkaç dahili ekibin bu özelliği kaynak kullanımını optimize etmek ve bellek yetersizliği (out-of-memory) hatalarını çözmek için kullandığını söylüyor; blog iki örneği ayrıntılarıyla anlatıyor.

İlk örnek, 50 saniye boyunca profillenmiş R2 binding'ini uygulayan Worker ile ilgili. Geniş kutular arasında decryptBlock ve fillResponse gibi beklenen maliyetler vardı, ancak tablo görünümünün örneklere göre sıralanması genericR2JsonReplacer'ı CPU süresinin %5'inden fazlasını işaret etti. Fonksiyon, JSON ağacındaki her düğüm için JSON.stringify tarafından çağrılırken ağacın kendisini de dolaşıyordu; dolayısıyla beş seviye derine gömülü bir değer beş kez işleniyordu. Bu yinelenen işi kaldırmak fonksiyonu 2,7 kat hızlandırdı. Aynı profil, tek bir çağrının CPU süresinin %1'ine mal olduğu registry.metrics() öğesine yapılan gereksiz bir çağrıyı da ortaya çıkardı; sonucun bir değişkende önbelleğe alınması bu israfı ortadan kaldırdı.

İkinci vaka, P999 bellek kullanımı 128 MB'lık Worker limitine karşı yaklaşık 133 MB olan dahili bir Worker'dı ve bu durum sık sık "Exceeded Memory" tahliyelerine (eviction) yol açıyordu. Hatalar ve metrikler sorunun bellek olduğunu doğruluyordu ama hangi kodun neden olduğunu söyleyemiyordu. pprof'ta açılan bir heap profili, Worker'ın Prometheus instrumentasyonunun tahsislerin yaklaşık %66,7'sinden sorumlu olduğunu gösterdi — ekibin devre dışı olduğunu varsaydığı, ancak yalnızca kısmen kapatılmış ve tam bellek maliyetini hâlâ ödeyen bir koddu. Bunun tamamen silinmesi şu sonucu verdi:

Yüzdelik	Önce	Sonra
P50	70 MB	54 MB
P90	94 MB	79 MB
P99	113 MB	97 MB
P999	133 MB	118 MB

Bu, P999'da limitin altında yaklaşık 10 MB'lık bir pay bıraktı ve "Exceeded Memory" hataları da aynı şekilde azaldı.

Edge'de profilleme neden zor

Workers, bir süredir Chrome DevTools aracılığıyla yerel profilleme destekliyor, ancak yerel bir oturum üretimdeki türde ve hacimde istekleri asla görmez. Edge'de üretim profilleme karmaşıklıklar ekliyor: Worker'lar istekleri istemcilere yakın tutmak için veri merkezlerine ve fiziksel sunuculara çoğaltılır ve Durable Objects dinamik olarak yerleştirilebilir, taşınabilir. Bir oturum başlatılmadan önce sistemin hangi sürümün profilleneceğini, hangi veri merkezinin yakın zamanda onu çalıştırdığını, isolate'in orada hâlâ yüklenmiş olup olmadığını, yalnızca istekte bulunan hesaba mı ait olduğunu ve bir Durable Object için canlı primary actor'ün nerede bulunduğunu çözmesi gerekir. İsteği yapan istemci, genellikle dashboard, bu yanıtların bir kısmını sağlar.

Neden önemli

Serverless hata ayıklama uzun süredir log'lara ve toplu metriklere dayandı; bunlar bir Worker'ın bellek limitini aştığını veya CPU tükettiğini söyleyebilir ama hangi fonksiyonun sorumlu olduğunu söyleyemez. Üretim flamegraph'ları bu boşluğu kapatıyor ve Workers katı bellek ve CPU üst sınırları uyguladığı için kazanç somut: daha az tahliye (eviction), daha iyi kuyruk (tail) gecikmesi ve daha az israf. Dahili örnekler durumu özetliyor — ne özyinelemeli JSON replacer ne de yarı devre dışı bırakılmış Prometheus kodu yalnızca dashboard'lardan açık olamazdı. Ölçekli Workers çalıştıran ekipler için bu, kaynak hata ayıklamayı tahminden hedefli bir araştırmaya dönüştürüyor.