Belajar Performance Test Engineer - Continuous Performance

#Pendahuluan

Setelah di episode 21 kita memahami shift-left performance engineering, kini saatnya membahas bagaimana menjaga performa tetap terjaga seiring waktu: continuous performance. Performance testing bukan one-time activity — ia harus berkelanjutan, terukur, dan terotomasi. Setiap commit bisa mengubah performa; setiap dependency update bisa mempengaruhi latency.

Continuous performance adalah philosophy: performance harus dipantau, diukur, dan divalidasi secara terus-menerus — bukan hanya saat release. Episode ini membawa kalian membangun sistem continuous performance testing.

#Baseline Management

#Apa itu Baseline

Baseline adalah titik referensi performa yang established — data yang menunjukkan "performa normal" untuk perbandingan. Tanpa baseline, kalian tidak tahu apakah performa membaik atau memburuk.

#Establishing Baseline

bash

# Jalankan test 5 kali untuk establish baseline
for i in {1..5}; do
  k6 run --out json=baseline-$i.json script.js
done
 
# Hitung rata-rata dan standard deviation
python scripts/calculate-baseline.py --files baseline-*.json

#Baseline Storage

Simpan baseline sebagai artifact yang bisa dirujuk:

yaml

# baseline-config.yml
endpoints:
  GET /products:
    p95: 180ms  # Baseline dari bulan lalu
    p99: 350ms
    throughput: 520 RPS
  POST /checkout:
    p95: 450ms
    p99: 800ms
    throughput: 120 RPS

#Trend Analysis

#Mengapa Trend Penting

Satu data point tidak bercerita banyak. Trend — bagaimana metrik berubah dari waktu ke waktu — memberikan insight yang jauh lebih dalam tentang kesehatan performa sistem.

#Dashboard Trend

Buat dashboard Grafana yang menampilkan tren performa dari waktu ke waktu:

promql

# Tren p95 latency harian
avg_over_time(http_request_duration_seconds{quantile="0.95"}[1d])
 
# Tren throughput mingguan
avg_over_time(rate(http_requests_total[5m])[7d:5m])
 
# Tren error rate bulanan
avg_over_time(rate(http_requests_total{status=~"5.."}[5m])[30d:5m])

#Anomaly Detection

Gunakan statistical methods untuk mendeteksi anomali secara otomatis:

python

# Deteksi anomali menggunakan Z-score
import numpy as np
 
def detect_anomaly(current, historical_mean, historical_std):
    z_score = (current - historical_mean) / historical_std
    return abs(z_score) > 2  # Anomali jika > 2 standard deviations

#Automated Performance Monitoring

#Synthetic Monitoring

Synthetic monitoring menjalankan test scripts secara berkala untuk memantau performa secara proaktif — seperti load test mini yang berjalan setiap jam.

yaml

# Synthetic monitoring schedule
name: Synthetic Performance Check
schedule: "*/30 * * * *"  # Setiap 30 menit
script: scripts/performance-check.js
vus: 5
duration: 2m
thresholds:
  http_req_duration: ['p(95)<300']
  http_req_failed: ['rate<0.01']

#Real User Monitoring (RUM)

RUM mengukur performa dari browser user nyata — memberikan data real-world yang tidak bisa digantikan oleh synthetic monitoring.

#Log-Based Monitoring

Monitor logs untuk detect performance issues:

promql

# Alert jika response time > 5 detik muncul lebih dari 10 kali per menit
rate(http_request_duration_seconds_bucket{le="5"}[1m]) > 10

#Continuous Benchmarking

#Benchmark Suite

Buat benchmark suite yang berjalan di setiap commit:

yaml

# GitHub Actions: continuous benchmark
name: Performance Benchmark
on:
  push:
    branches: [main]
 
jobs:
  benchmark:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run benchmark
        run: k6 run --out json=benchmark.json scripts/benchmark.js
      - name: Compare with baseline
        run: python scripts/compare-with-baseline.py --current benchmark.json --baseline baseline.json

#Benchmark Comparison

python

def compare_benchmarks(baseline, current, tolerance=5):
    results = {}
    for endpoint in baseline:
        base_p95 = baseline[endpoint]['p95']
        curr_p95 = current[endpoint]['p95']
        change_pct = ((curr_p95 - base_p95) / base_p95) * 100
 
        results[endpoint] = {
            'baseline': base_p95,
            'current': curr_p95,
            'change_pct': change_pct,
            'regression': change_pct > tolerance,
        }
    return results

#Performance Alerting

#Alert Rules

yaml

# Prometheus alerting rules
groups:
  - name: performance
    rules:
      - alert: HighLatency
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "p95 latency above 500ms for 5 minutes"
 
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 2 minutes"

#Alert Fatigue Management

Severity levels: warning vs critical
Duration requirement: alert harus bertahan minimal beberapa menit
Escalation: warning → critical → on-call → management
Runbooks: setiap alert harus punya remediation steps

#Performance Culture

#Membangun Budaya

Continuous performance membutuhkan budaya organisasi yang mendukung:

Metrics visibility: semua orang bisa melihat performa
Blameless post-mortems: fokus pada perbaikan, bukan menyalahkan
Performance budget: anggaran performa yang harus dipatuhi
Regular reviews: performance review di sprint planning

#Penutup

Di episode 22 ini kalian telah memahami continuous performance:

Baseline management: establish dan maintain referensi performa.
Trend analysis: monitor perubahan dari waktu ke waktu.
Synthetic monitoring: automated test yang berjalan berkala.
Continuous benchmarking: benchmark di setiap commit.
Performance alerting: deteksi degradation secara real-time.

Di episode 23 selanjutnya, kita akan membahas AI Workload Performance — testing GPU performance, LLM inference latency, dan tantangan performance testing untuk AI systems. Siapkan GPU profiling kalian!