Belajar Performance Test Engineer - Analysis & Bottleneck Detection

#Pendahuluan

Setelah di episode 9 kita memahami monitoring stack (Prometheus, Grafana, distributed tracing), kini saatnya mengaplikasikan pemahaman itu dalam bentuk yang paling berharga: menganalisis data untuk menemukan bottleneck. Load test yang menghasilkan data tanpa analisis adalah pemborosan waktu — analisis adalah bagian yang mengubah data menjadi insight yang actionable.

Performance analysis adalah seni dan sains: seni karena membutuhkan intuisi untuk menghubungkan pola dalam data; sains karena berbasis metrik yang terukur. Episode ini membawa kalian dari mengumpulkan data hingga menyusun rekomendasi perbaikan.

#Correlating Metrics

#Prinsip Dasar

Bottleneck selalu memiliki gejala dan akar masalah. Gejala adalah yang kalian lihat di k6 (latency naik, error rate meningkat). Akar masalah adalah yang terjadi di server (CPU tinggi, memory penuh, database lock). Analysis yang baik menghubungkan keduanya.

#Langkah Analysis

1. Identifikasi gejala: kapan latency naik? di mana error rate melonjak?
2. Korelasikan dengan system metrics: pada saat yang sama, apa yang terjadi di CPU, memory, disk, network?
3. Korelasikan dengan application metrics: berapa banyak connection aktif? berapa banyak thread?
4. Korelasikan dengan database metrics: berapa lama query time? ada lock contention?
5. Temukan akar masalah: resource mana yang kehabisan kapasitas?

#Contoh Correlation

Waktu 14:30 - 14:35:
- k6: latency p95 naik dari 200ms ke 800ms
- Prometheus: CPU usage naik dari 40% ke 95%
- PostgreSQL: active connections naik dari 20 ke 100
- Application: connection pool size = 50
 
Kesimpulan: connection pool exhaustion → requests menunggu koneksi → latency naik

#Flame Graphs

Flame graph adalah visualisasi yang menunjukkan di mana CPU time dihabiskan oleh aplikasi. Setiap bar adalah function call; lebar bar menunjukkan proporsi CPU time. Flame graph membantu menemukan function yang paling banyak memakan CPU.

#Membuat Flame Graph

# Menggunakan py-spy (Python)
py-spy record -o profile.svg --duration 30 --pid $(pgrep -f "python app.py")
 
# Menggunakan perf (Linux)
perf record -g -p $(pgrep -f "node app.js") -- sleep 30
perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > profile.svg

#Membaca Flame Graph

• Bar lebar = function yang menghabiskan banyak CPU time
• Stack tinggi = deep call stack (bisa jadi recursive atau complex pipeline)
• Tindakan: fokus optimasi pada function dengan bar paling lebar

#Profiling

#CPU Profiling

CPU profiling merekam aktivitas CPU secara periodik — menghasilkan data tentang function mana yang sedang dieksekusi. Dari profiling data, kalian bisa membuat flame graph atau analisis statistik.

# Node.js: built-in profiler
node --prof app.js
node --prof-process isolate-*.log > processed.txt

#Memory Profiling

Memory profiling mengidentifikasi di mana memory dialokasikan dan apakah ada leak:

# Go: pprof
go tool pprof http://localhost:6060/debug/pprof/heap
 
# Java: jmap + jhat
jmap -dump:live,format=b,file=heapdump.hprof <pid>

#Database Profiling

Database profiling mengungkap query lambat dan execution plans:

-- PostgreSQL: analisis query
EXPLAIN ANALYZE SELECT * FROM products WHERE category_id = 5 ORDER BY created_at DESC;
 
-- Lihat execution plan untuk menemukan sequential scan yang tidak perlu

#Root Cause Analysis

#Metode 5 Whys

Tanyakan "mengapa" secara berulang sampai menemukan akar masalah:

1. "Mengapa latency tinggi?" → "Karena CPU usage tinggi"
2. "Mengapa CPU tinggi?" → "Karena garbage collection sering berjalan"
3. "Mengapa GC sering?" → "Karena memory allocation tinggi"
4. "Mengapa memory allocation tinggi?" → "Karena aplikasi membuat terlalu banyak object di loop"
5. "Mengapa loop membuat banyak object?" → "Karena tidak ada object pooling" → INI AKAR MASALAH

#Ishikawa Diagram (Fishbone)

Diagram Ishikawa membantu mengorganisasi kemungkinan akar masalah dalam kategori:

• Infrastructure: CPU, memory, disk, network
• Application: code quality, architecture, dependencies
• Database: queries, indexing, connection pool
• Configuration: timeout, pool size, thread count
• Traffic pattern: distribution, spike, think time

#Menyusun Rekomendasi

#Format Rekomendasi yang Baik

Rekomendasi harus specific, measurable, dan actionable:

#Presentasi ke Stakeholder

Saat mempresentasikan hasil analysis ke stakeholder non-technical:

1. Mulai dari impact bisnis: "Checkout flow lambat menyebabkan 15% cart abandonment"
2. Tunjukkan data: grafik latency, error rate, throughput
3. Jelaskan akar masalah: dengan bahasa sederhana
4. Berikan rekomendasi: dengan estimasi dampak dan effort

#Penutup

Di episode 10 ini kalian telah memahami analysis & bottleneck detection:

• Correlating metrics: menghubungkan gejala (latency) dengan akar masalah (CPU, memory, database).
• Flame graphs: visualisasi CPU time untuk menemukan function yang paling berat.
• Profiling: CPU, memory, dan database profiling untuk identifikasi bottleneck.
• Root cause analysis: metode 5 Whys dan Ishikawa diagram.
• Rekomendasi: specific, measurable, actionable — dengan impact bisnis.

Di episode 11 selanjutnya, kita akan membahas Capacity Planning — bagaimana menggunakan data performance test untuk merencanakan infrastruktur, forecasting, dan budgeting yang tepat. Siapkan spreadsheet kalian!