Profiling ve Uygulama Performansı
Performans optimizasyonu, ölçülmüş bir darboğazı kullanıcı etkisi ve kapasite hedefiyle ilişkilendirerek azaltma sürecidir. Profiling yapılmadan cache, thread veya instance eklemek semptomu gizleyebilir ve maliyeti artırabilir.
Hızlı Karar
| Belirti | Önce ölç | Tipik müdahale |
|---|---|---|
| Yüksek CPU | CPU profile, allocation, serialization | Algoritma, batch, thread ve payload |
| Bellek artışı | Heap/live object, GC, allocation profile | Lifecycle, cache bound, leak |
| Yavaş API | Trace, DB query plan, downstream latency | Query/index, parallelism, timeout |
| Düşük throughput | Queue, pool saturation, lock contention | Backpressure, pool ve ölçekleme |
Üretim Kontrol Listesi
- Problem: Hangi kullanıcı akışı veya SLO etkileniyor?
- Çözüm: Baseline, hipotez, değişiklik ve before/after ölçümü var mı?
- Trade-off: Daha düşük latency; daha fazla cache, CPU, memory veya operasyon maliyeti getirebilir.
- Hata durumu: Cache stampede, thread starvation, pool exhaustion, GC pause ve compression CPU'su incelenmeli.
- Ölçüm: p50/p95/p99, throughput, error rate, CPU, memory, GC, queue age ve unit cost birlikte izlenmeli.
- Güvenlik/maliyet: Profil verisi PII sızdırmamalı; production profiling sampling ve retention ile sınırlandırılmalı.
Profiling Metodu
- Temsilî trafik ve workload için baseline al.
- CPU, allocation/heap, lock, I/O ve database trace sinyallerini ayır.
- Tek hipotezi değiştirecek küçük bir müdahale yap.
- Aynı workload altında latency, error ve resource sonuçlarını karşılaştır.
- Kazancı ve yeni trade-off'u ADR veya performance record'a yaz.
Sampling profiler genel hot path'i gösterir; tracing request'in hangi hop'ta beklediğini gösterir; heap dump retained object ve leak için kullanılır. Profiling aracının kendisi latency ve storage ekleyebilir, bu nedenle süre ve kapsam kontrollü olmalıdır.
API ve IO Optimizasyonu
- Response DTO'da yalnızca gerekli alanları taşı; pagination ve field selection ile payload'ı sınırla.
- gzip/Brotli compression'ı büyük text payload'larda kullan; küçük payload'da CPU maliyetini ölç.
- HTTP client connection pool, keep-alive, connect/read timeout ve max pending request sınırlarını ayrı ayarla.
- Bağımsız downstream çağrılarını bounded parallelism ile çalıştır; deadline propagation olmadan paralellik timeout'u büyütebilir.
- Lazy loading'i yalnızca erişim paterni ve transaction sınırı net olduğunda kullan; ORM'de gizli N+1 üretme.
Database ve Cache
Query planı, index selectivity, lock wait, pool utilization ve replica lag ölçülmeden yalnızca cache eklenmemelidir. Repository/ORM abstraction sorgunun gerçek maliyetini gizleyebilir.
Cache hit, miss, eviction, hot key, stampede ve origin fallback izlenir. Cache warming, yalnızca popüler ve düşük değişkenlikli veriler için bounded yapılmalı; deploy sırasında origin'i aynı anda yüklememelidir.
Ölçekleme
Yatay ölçekleme stateless application, load distribution ve autoscaling ile kapasiteyi artırır; bottleneck database, license veya shared connection pool ise instance artırmak çözüm değildir. Dikey ölçekleme daha büyük CPU/memory ile basittir fakat tek node sınırı ve maliyet artışı getirir.
Autoscaling sinyali yalnızca CPU olmamalı; request concurrency, queue age, latency, error budget ve downstream saturation da değerlendirilmelidir. CDN, static asset ve cacheable response'ları edge'e taşıyabilir; kişisel veya authorization bağımlı response'lar dikkatle ayrılmalıdır.
Sonuç
Başarılı optimizasyon, ölçümde anlamlı iyileşme sağlarken correctness, security, availability ve cost hedeflerini bozmaz. Profil sonucu, değişiklik, beklenen kazanım ve rollback sinyali birlikte kaydedilmelidir.