Claude Code ile performans incelemeleri: ölçümlü bir iş akışı

Neden ölçüm olmadan performans çalışmaları yanlış gider

Performans hataları tahmine davet eder. Birisi bir sayfanın yavaş hissettirdiğini ya da bir API'nin zaman aşımına uğradığını fark eder ve en hızlı hamle genellikle kodu "düzeltmek", önbellek eklemek veya bir döngüyü yeniden yazmaktır. Sorun şu ki "yavaş hissetme" bir metrik değildir ve "daha temiz" her zaman daha hızlı demek değildir.

Ölçüm yoksa ekipler yanlış şeyi değiştirerek saatler harcar. Sıcak yol (hot path) veritabanında, ağda veya beklenmedik bir tahsisatta olabilirken ekip neredeyse hiç çalışma yapmayan kodu parlatır. Daha kötüsü, akıllıca görünen bir değişiklik performansı kötüleştirebilir: sık döngüde ekstra logging, belleği artıran bir önbellek veya kilit yarışına yol açan paralel işler.

Tahmin yürütmek ayrıca davranışın bozulma riskini artırır. Hızı artırmak için kodu değiştirdiğinizde sonuçları, hata işleyişini, sıralamayı veya tekrar denemeleri etkileyebilirsiniz. Doğruluk ve hızı birlikte tekrar kontrol etmezseniz, bir kıyaslamada "kazanıp" sessizce bir hata gönderme riskiniz olur.

Performansı tartışma gibi değil deney gibi ele alın. Döngü basit ve tekrarlanabilirdir:

• Sıkıntıyı temsil eden tek bir metrik seçin (latency, throughput, CPU, bellek, DB zamanı).
• Aynı koşullar altında bir baz değer (baseline) alın.
• Bir küçük değişiklik yapın.
• Tekrar ölçün ve karşılaştırın.

Birçok kazanım mütevazıdır: p95 gecikmeden %8 kesinti, tepe bellek kullanımında 50 MB azalma veya bir veritabanı sorgusunun kaldırılması. Bu kazanımlar yine de önemlidir; ama yalnızca ölçüldüklerinde, doğrulandıklarında ve tekrarlanabildiklerinde.

İş akışı: ölç, hipotez kur, değiştir, yeniden ölç

Bu bir döngü olarak çalıştığında en etkilidir, tek seferlik "daha hızlı yap" isteği değil. Döngü sizi dürüst tutar çünkü her eylem kanıta ve izleyebileceğiniz bir sayıya bağlanır.

Açık bir sıra:

• Ölçün: bir metrik seçin ve baz değeri kaydedin.
• Hipotez kurun: neyin yavaş olduğunu ve nedenini açıklayın.
• Değiştirin: hipotezi test edecek en küçük ayarı yapın.
• Yeniden ölçün: aynı ölçümü tekrar çalıştırın ve karşılaştırın.

Her adım farklı bir yanıltmayı engeller. Önce ölçmek, gerçek bir problem olmayanı "düzeltmenizi" engeller. Yazılı bir hipotez, aynı anda beş şeyi değiştirip hangisinin etkili olduğunu tahmin etmeyi engeller. Minimal değişiklikler davranışı bozma veya yeni darboğazlar ekleme riskini azaltır. Yeniden ölçmek, ısınmış önbellekten kaynaklanan sahte kazanımları yakalar ve gerilemeleri açığa çıkarır.

"Bitti" bir his değildir. Sonuçtur: hedef metrik doğru yönde hareket etti ve değişiklik belirgin gerilemelere (hatalar, daha yüksek bellek, kötüleşen p95, ya da çevre uç noktaların yavaşlaması) neden olmadı.

Ne zaman durulacağını bilmek iş akışının bir parçasıdır. Kazançlar düzleştiğinde, metrik kullanıcılar için yeterince iyi olduğunda veya bir sonraki fikir büyük refaktörler gerektirip küçük fayda sağlayacağında durun. Performans çalışması her zaman fırsat maliyeti taşır; döngü zamanı kazandıran yerlere odaklanmanıza yardımcı olur.

Metrik seçin ve baz değeri kilitleyin

Aynı anda beş şeyi ölçerseniz neyin iyileştiğini bilemezsiniz. Bu inceleme için bir birincil metrik seçin ve diğerlerini destekleyici sinyaller olarak değerlendirin. Kullanıcıya dönük birçok problem için bu metrik gecikmedir. Batch işler için throughput, CPU süresi, bellek kullanımı veya hatta çalıştırma başına bulut maliyeti olabilir.

Senaryoya özgü olun. "API yavaş" çok belirsizdir. "3 öğelik tipik bir sepet ile POST /checkout" ölçülebilir. Girdileri sabit tutun ki sayılar bir anlam taşısın.

Koda dokunmadan önce baz değeri ve ortam detaylarını yazın: veri seti boyutu, makine tipi, build modu, feature flagler, eşzamanlılık ve ısınma. Bu baz değerinizin demiridir. Onsuz her değişiklik ilerleme gibi görünebilir.

Gecikme için ortalamaya değil yüzdeliklere (percentiles) güvenin. p50 tipik deneyimi, p95 ve p99 ise kullanıcıların şikâyet ettiği acı veren kuyruğu gösterir. p50 iyileşirken p99 kötüleşirse sistem yine de daha yavaş hissedilebilir.

"Anlamlı" olmanın ne demek olduğunu baştan kararlaştırın ki gürültüyü kutlamayın:

• Gecikme: p95'te en az %10 iyileşme (veya 50 ms gibi sabit eşik)
• Throughput: aynı hata oranında en az %5 artış
• CPU veya bellek: ölçeklemeyi veya çöküşleri önleyecek kadar azalma
• Maliyet: çalıştırma başına veya 1.000 istek başına ölçülebilir düşüş

Bu kurallar konulduktan sonra, fikirleri test ederken hedefi kaydırmazsınız.

Profilleme ve basit metriklerle kanıt toplayın

Güvenebileceğiniz en kolay sinyal ile başlayın. Bir isteğin tek bir zamanlaması, gerçek bir problemin olup olmadığını ve kabaca ne kadar büyük olduğunu söyleyebilir; neden yavaş olduğunu açıklamak için derin profilleme saklayın.

İyi kanıt genellikle bir karışım kaynaklardan gelir:

• Uygulama logları (istek süresi, hata oranı, en yavaş uç noktalar)
• APM izleri (servisler arası zaman dağılımı)
• Profiler çıktısı veya flame graph'ler (sıcak fonksiyonlar ve çağrı yığınları)
• Veritabanı istatistikleri (yavaş sorgular, kilit beklemeleri, önbellek vuruş oranı)
• Altyapı metrikleri (CPU, bellek, ağ, container yeniden başlatmaları)

Soru "daha yavaş mı ve ne kadar?" ise basit metrikler kullanın. Soru "zaman nereye gidiyor?" ise profilleme kullanın. Bir deploy sonrası p95 iki katına çıktıysa önce regresyonu onaylamak ve kapsamlamak için zamanlamalar ve loglarla başlayın. Zamanlamalar gecikmenin çoğunun uygulama içinde olduğunu gösteriyorsa (DB değil), bir CPU profiler veya flame graph hangi fonksiyonun büyüdüğünü gösterebilir.

Ölçümleri güvenli tutun. Performansı debug etmek için gerekeni toplayın, kullanıcı içeriğini değil. Ham payloadlar yerine özetleri (süreler, sayılar, boyutlar) tercih edin ve varsayılan olarak tanımlayıcıları gizleyin.

Gürültü gerçek olduğundan birden çok örnek alın ve aykırı değerleri not edin. Aynı isteği 10 ila 30 kez çalıştırın ve tek en iyi çalıştırma yerine medyan ve p95'i kaydedin.

Tam olarak aynı testi tekrarlayabilmeniz için test tarifini yazın: ortam, veri seti, uç nokta, istek gövde boyutu, eşzamanlılık seviyesi ve sonuçları nasıl aldığınız.

Kanıtı net bir hipoteze dönüştürün

Semptomu adlandırarak başlayın: "p95 gecikme trafik zirvelerinde 220 ms'den 900 ms'ye çıkıyor", "CPU iki çekirdekte %95'te oturuyor" veya "bellek saatte 200 MB artıyor." "Yavaş hissetme" gibi belirsiz semptomlar rastgele değişikliklere yol açar.

Sonra ölçtüklerinizi şüpheli bir alana çevirin. Bir flame graph çoğu zamanı JSON serileştirmede gösteriyor olabilir, bir trace yavaş bir çağrı yolunu gösterebilir veya veritabanı istatistikleri tek bir sorgunun toplam zamanın çoğunu kapsadığını gösterebilir. Maliyetin çoğunu açıklayan en küçük alanı seçin: bir fonksiyon, tek bir SQL sorgusu veya bir dış çağrı.

İyi bir hipotez bir cümle, test edilebilir ve bir öngörüye bağlıdır. Yardım isterken bir aracın sihirli şekilde her şeyi hızlandırmasını istemiyorsunuz; fikir test edilecek şekilde sunulmalı.

Basit bir hipotez şablonu

Bu formatı kullanın:

• Çünkü (kanıt) nedeniyle (şüpheli) (semptoma) neden oluyor.
• Eğer (spesifik davranış) değişirse, (metrik) yaklaşık (tahmini miktar) kadar iyileşmeli.
• Başarılı olduğunu (yeniden ölçüm sonucu) ile anlayacağız.

Örnek: "Profil CPU'nun %38'ini SerializeResponse içinde gösterdiği için her istek başına yeni bir buffer tahsisi CPU spike'larına neden oluyor. Eğer buffer'ı yeniden kullanırsak, p95 gecikme yaklaşık %10-20 düşmeli ve CPU aynı yük altında %15 azalmalı."

Kodu değiştirmeden önce alternatifleri de isimlendirerek dürüst kalın. Yavaş bölüm aslında upstream bağımlılık olabilir, kilit yarışması, önbellek vuruş oranı değişimi veya payload boyutunu artıran bir rollout olabilir.

2-3 alternatif açıklamayı yazın, sonra kanıtın en iyi desteklediğiyle başlayın. Değişiklik metrikleri hareket ettirmezse zaten bir sonraki hipoteziniz hazır olur.

Claude Code'u tahmine kaymadan nasıl kullanmalı

Claude, performans çalışmalarında dikkatli bir analist gibi kullanıldığında en faydalıdır, kehanet mercii gibi değil. Her öneriyi ölçtüğünüzle ilişkilendirin ve her adımın yanlışlanabilir olduğundan emin olun.

Vagu olmayan, gerçek girdiler verin. Küçük, odaklanmış kanıtları yapıştırın: bir profilleme özeti, yavaş isteğe ait birkaç log satırı, bir sorgu planı ve spesifik kod yolu. "Önce" sayıları (p95, CPU zamanı, DB zamanı) dahil edin ki başlangıç bilgisi olsun.

Veri ne önerdiğini ve neyi desteklemediğini açıklamasını isteyin. Sonra rakip açıklamaları zorlayın. Kullanışlı bir prompt şu cümleyle bitmeli: "Bana 2-3 hipotez ver, ve her biri için neyle yanlışlanacağını söyle." Bu, ilk makul hikâyeye takılmayı engeller.

Herhangi bir şeye dokunmadan önce en küçük deneyi isteyin ki önder hipotezi doğrulanabilsin. Hızlı ve geri alınabilir olsun: bir fonksiyonun etrafına zamanlayıcı ekleyin, bir profiler flag'i açın ya da bir DB sorgusunu EXPLAIN ile çalıştırın.

Çıktı için sıkı bir yapı istiyorsanız şu şekilde isteyin:

• Kanıtın ne gösterdiği (ve güven seviyesi)
• 2-3 hipotez ve her biri için yanlışlama testi
• En üst hipotezi test etmek için en küçük kod veya yapılandırma değişikliği
• Yeniden ölçülecek metrik ve beklenen yön

Eğer belirli bir metrik, yer ve beklenen sonuç adımı yoksa yine tahmine dönmüşsünüz demektir.

Minimal, geri alınabilir değişiklikler yapın

Kanıtınız ve hipoteziniz olduktan sonra her şeyi "temizlemeye" kalkışmayın. Performans çalışması en güvenilir olduğunda kod değişikliği küçük ve kolay geri alınabilir olmalıdır.

Aynı anda birden fazla şeyi değiştirmeyin. Bir sorguda ince ayar yapıp aynı commit'te önbellek ekleyip döngüyü refactor ederseniz hangi değişikliğin etkili olduğunu bilemezsiniz. Tek değişkenli değişiklikler bir sonraki ölçümü anlamlı kılar.

Koda dokunmadan önce sayısal beklentinizi yazın. Örnek: "p95 gecikme 420 ms'den 300 ms altına düşmeli ve DB zamanı yaklaşık 100 ms azalmalı." Sonuç bu hedefin altında kaldıysa hipotezin zayıf veya eksik olduğunu çabuk öğrenirsiniz.

Değişiklikleri geri alınabilir tutun:

• Temiz bir revert edilebilen küçük diff tercih edin.
• Değişikliği basit bir flag'in arkasına koyun ki hızlı kapatılabilsin.
• İsim değişiklikleri, biçimlendirme ve mantık değişikliklerini performans tweakleriyle karıştırmayın.
• Kapsamı dar tutun: bir uç nokta, bir sıcak yol, bir pahalı çağrı.
• Commit mesajına beklenen önce/sonra metriklerini kısa not edin.

"Minimal" önemsiz demek değildir; odaklanmış demektir: pahalı bir fonksiyonun sonucunu önbelleğe almak, sık döngüde tekrar eden bir tahsisi kaldırmak veya gereksiz işleri istekler için yapmayı durdurmak.

Şüpheli darboğazın etrafına hafif zamanlayıcı ekleyin ki neyin hareket ettiğini görün. Bir çağrı öncesi ve sonrası zaman damgası (loglanan veya metrik olarak yakalanan) değişikliğin gerçekten yavaş kısmı hedefleyip hedeflemediğini doğrular.

Yeniden ölçün ve sonraki adımı kararlaştırın

Bir değişiklikten sonra baz değeri aldığınız ile aynı senaryoyu tekrar çalıştırın: aynı girdiler, ortam ve yük şekli. Testiniz önbelleklere veya ısınmaya bağlıysa bunu açıkça belirtin (örneğin: "ilk deneme cold, sonraki 5 deneme warm"). Aksi halde şanslı bir iyileşmeyi gerçekmiş gibi bulabilirsiniz.

Aynı metrik ve aynı yüzdelikleri kullanarak karşılaştırın. Ortalamalar acıyı gizleyebilir; p95 ve p99 gecikmeye, throughput ve CPU zamanına dikkat edin. Sayıların yerleşip yerleşmediğini görmek için yeterli tekrarı çalıştırın.

Kutlamadan önce başlık sayının dışında gerilemeleri kontrol edin:

• Doğruluk: yanıtlar beklenen çıktıyla eşleşiyor mu
• Hata oranı: zaman aşımı, 5xx, retry'ler
• Bellek: daha yüksek tepe veya süreklilik gösteren artış
• Kuyruk gecikmesi: p99 kötüleşti mi
• Kaynak maliyeti: CPU veya DB yükünde sıçrama

Sonra umudun değil kanıtın gösterdiğine göre karar verin. İyileşme gerçekse ve gerileme yoksa devam edin. Sonuç karışık veya gürültülü ise revert edin ve yeni hipotez kurun veya değişikliği daha da izole edin.

Koder.ai gibi bir platformda çalışıyorsanız, deneye başlamadan önce bir snapshot almak geri dönüşü tek adım yapabilir; bu da cesur fikirleri güvenle denemeyi kolaylaştırır.

Son olarak öğrendiklerinizi yazın: baz değer, değişiklik, yeni sayılar ve sonuç. Bu kısa kayıt bir sonraki turun aynı çıkmazları tekrarlamamasını sağlar.

Zaman kaybettiren yaygın hatalar

Performans çalışması genellikle ölçtüğünüzle değiştirdikleriniz arasındaki bağlantıyı kaybettiğinizde sapar. Neyin daha iyi veya daha kötü yaptığını güvenle söyleyebilmeniz için kanıt zincirini temiz tutun.

Tekrarlayan hatalar:

• Yan hedefi düzeltmek: medyan (p50) hızlanıyor ama kuyruk (p95/p99) hâlâ kötü.
• Aynı anda bir sürü şeyi değiştirmek: refactor, önbellekleme ve sorgu tweak'lerini tek committe yapmak hangi değişikliğin etkili olduğunu bilinmez kılar.
• Gürültülü tek bir çalıştırmaya inanmak: yerel benchmarklar arasında %20 oynama olan tek bir sonuç kanıt değildir.
• Tek bir profili tüm gerçeğin yerine koymak: flame graph JSON parsing'i işaretleyebilir, ama istekler DB yavaşladığında birikiyor olabilir.
• Elma ile armut karşılaştırmak: farklı veri setleri, feature flagler, donanım veya eşzamanlılık seviyeleriyle karşılaştırıp yine de sonuç çıkarmak.

Küçük bir örnek: bir uç nokta yavaş görünüyor, profilde serializer sıcak olduğu için onu ayarlıyorsunuz. Sonra daha küçük bir veri setiyle yeniden test edip daha hızlı olduğunu görüyorsunuz. Prod ortamında p99 kötüleşiyor çünkü veritabanı hâlâ darboğaz ve değişiklik payload büyüterek durumu kötüleştirmiş olabilir.

Claude Code kullanarak düzeltme önerileri alıyorsanız kısa bir leşe alın. Topladığınız kanıtlara uyan 1-2 minimal değişiklik isteyin ve bir yama kabul etmeden önce yeniden ölçme planı talep edin.

"Daha hızlı" dediğinizden emin olmadan önceki kısa kontrol listesi

Test bulanıksa hız iddiaları çöker. Kutlamadan önce neyi ölçtüğünüzü, nasıl ölçtüğünüzü ve neyi değiştirdiğinizi açıklayabildiğinizden emin olun.

Bir metrik adımlayın ve baz değeri ortam notlarıyla yazın (donanım, konfig, veri, build modu, feature flag, önbellek durumu). Yarın aynı ortamı yeniden oluşturamıyorsanız baz değeriniz yoktur.

Kontrol listesi:

• Metrik ve baz değer ortam notlarıyla kaydedildi (donanım, konfig, veri, sıcak/soğuk önbellek).
• Test adımları yazılı ve tekrarlanabilir.
• Bir hipotez ve tahmini hareket (ör. "N+1 sorgular kaldırılırsa p95 ~%30 düşer")
• Bir küçük, geri alınabilir değişiklik yaptınız ve tam olarak hangi dosyanın/fonksiyonun/sorgunun taşındığını belgelendirdiniz.
• Aynı girdilerle, aynı yük ile yeniden ölçtünüz ve karşılaştırdınız.

Sayılar daha iyi görünüyorsa hızlı bir regresyon kontrolü yapın: doğruluk, hata oranı ve zaman aşımı kontrolü. Daha yüksek bellek, CPU spike'ları, daha yavaş başlatma veya daha fazla DB yükü gibi yan etkileri izleyin. p95'i iyileştirip belleği iki katına çıkaran bir değişiklik yanlış bir takastır.

Örnek: yavaş bir API uç noktasını adım adım incelemek

Bir ekip GET /orders'ın geliştirmede iyi göründüğünü, ancak orta yükte staging'de yavaşladığını bildiriyor. Kullanıcılar zaman aşımından şikâyet ediyor, ama ortalama gecikme hâlâ "kabul edilebilir" görünüyor ki bu klasik bir tuzaktır.

Önce bir baz değer belirleyin. Sabit bir yük testi altında (aynı veri seti, aynı eşzamanlılık, aynı süre) kaydettiğiniz değerler:

• p95 gecikme: 1.8s (hedef < 600ms)
• API CPU: ~%70 ara sıra spike'lar
• DB: bir sorgu 900-1100ms alıyor ve istek başına toplam sorgu süresi ~1.3s

Sonra kanıt toplayın. Hızlı bir trace, uç noktanın ana bir sipariş sorgusu çalıştırdığını, sonra her sipariş için ilişkili öğeleri döngüyle çektiğini gösteriyor. JSON yanıtı büyük, ama DB zamanı baskın.

Bunu test edilebilir hipotezlere çevirin:

• Yavaş sorguya index eklemek gerekebilir.
• N+1 sorguları DB zamanını katlıyor.
• Serileştirme büyük payload yüzünden yavaş.
• Yazmalar sırasında kilit yarışması okumaları geciktiriyor.

En güçlü kanıta uyan minimal değişikliği isteyin: açık bir N+1 çağrısını kaldırarak order ID'lerine göre tek sorgu ile yüklenmesini sağlamak (veya yavaş sorgu planı tam taramayı gösteriyorsa eksik indexi eklemek). Değişiklik reversible ve odaklı bir commit olsun.

Aynı yük testiyle yeniden ölçün. Sonuçlar:

• p95 gecikme: 1.8s -> 720ms
• Toplam DB zamanı: ~1.3s -> 420ms
• CPU: hafifçe daha düşük, ama hâlâ spike'lar var

Karar: düzeltmeyi gönderin (açık kazanım), sonra kalan fark ve CPU spike'ları için ikinci turu başlatın çünkü DB artık ana sınırlayıcı değil.

Sonraki adımlar: bu iş akışını rutin hâline getirin

Performans incelemelerinde daha hızlı gelişmenin en iyi yolu her deneyi küçük, tekrarlanabilir bir deney gibi ele almaktır. Süreç tutarlı olduğunda sonuçlar güvenilir, karşılaştırılabilir ve paylaşılabilir olur.

Basit bir tek sayfa şablon yardımcı olur:

• Metrik + nasıl ölçüldüğü (araç, komut, veri seti)
• Baz değer (sayılar, ortam ve alındığı zaman)
• Hipotez (tek cümle, test edilebilir)
• Değişiklik (küçük diff, dokunulanlar)
• Sonuç (önce/sonra ve karar)

Bu notların nerede tutulacağına karar verin ki kaybolmasın. Paylaşılan bir yer mükemmel araçtan daha önemlidir: servis yanında bir repo klasörü, ekip dokümanı veya ticket notları olabilir. Birinin "önbellek değişikliğinden sonra p95 spike'ı" gibi bir kaydı aylar sonra bulabilmesi gerekir.

Güvenli deneyleri alışkanlık haline getirin. Snapshot'lar ve kolay rollback kullanarak bir fikri korkmadan deneyin. Eğer Koder.ai ile geliştiriyorsanız, Planning Mode ölçüm planını, hipotezi ve değişiklik kapsamını tanımlamak için uygun bir yer olabilir; böylece sıkı bir diff üretilmeden önce yeniden ölçme planı hazır olur.

Bir ritim belirleyin. Olayları beklemeyin. Yeni sorgular, yeni uç noktalar, daha büyük payloadlar veya bağımlılık yükseltmeleri sonrası küçük performans kontrolleri ekleyin. Şimdi yapılacak 10 dakikalık bir baz kontrolü ileride bir günlük tahmin yürütmeyi engelleyebilir.