Belajar Performance Test Engineer - Cloud & Serverless Performance

#Pendahuluan

Setelah di episode 15 kita memahami caching & CDN testing, kini saatnya membahas area yang semakin relevan di 2026: cloud & serverless performance. Semakin banyak aplikasi yang berpindah ke cloud-native architectures — containers, serverless functions, dan managed services — yang membawa tantangan performance testing yang unik.

Serverless cold start, autoscaling lag, dan container startup time adalah jenis bottleneck baru yang tidak ada di tradisional on-premise testing. Episode ini membawa kalian memahami tantangan ini dan cara mengujinya.

#Serverless Cold Start

#Apa itu Cold Start

Cold start adalah delay yang terjadi saat serverless platform (AWS Lambda, Google Cloud Run) harus menginisialisasi instance baru untuk menangani request. Cold start bisa menambahkan ratusan milidetik sampai beberapa detik ke response time.

#Faktor yang Mempengaruhi Cold Start

#Testing Cold Start

// k6: test cold start scenario
export const options = {
  scenarios: {
    cold_start: {
      executor: 'constant-arrival-rate',
      rate: 1,
      timeUnit: '1s',
      duration: '1m',
      preAllocatedVUs: 1,
    },
  },
};
 
export default function () {
  const res = http.get('https://api.example.com/endpoint');
  // Cold start terjadi di request pertama setelah idle
  // Response time pertama akan jauh lebih tinggi dari berikutnya
  check(res, {
    'status 200': (r) => r.status === 200,
  });
}

#Mitigasi Cold Start

• Provisioned concurrency: biarkan instance tetap hangat (bayar lebih)
• Minimize package size: kurangi dependencies
• Optimize runtime: gunakan runtime yang startup-nya cepat (Go, Rust)
• Keep-warm trick: periodic ping untuk mencegah instance sleep

#Autoscaling Testing

#Autoscaling Lag

Autoscaling lag adalah waktu antara load naik sampai instance baru benar-benar available. Selama lag ini, instance yang ada menangani semua beban — menyebabkan latency tinggi atau error.

#Testing Autoscaling

// k6: test autoscaling behavior
export const options = {
  stages: [
    { duration: '1m', target: 10 },    // Normal load
    { duration: '30s', target: 100 },  // Spike: autoscaling triggered
    { duration: '3m', target: 100 },   // Steady-state: instances should be scaled up
    { duration: '1m', target: 10 },    // Scale down
    { duration: '2m', target: 10 },    // Observe scale-down behavior
  ],
};

#Yang Diperhatikan

• Scaling time: berapa lama dari spike sampai instance baru available?
• Scaling accuracy: apakah scaler menambah jumlah instance yang tepat?
• Scale-down behavior: apakah instance di-terminate terlalu cepat (thrashing)?

#Container Performance

#Container Startup Time

Container startup time mempengaruhi autoscaling — semakin cepat startup, semakin cepat new instances available.

# Ukur container startup time
time docker run --rm grafana/k6 version
 
# Ukur di Kubernetes
kubectl get events --field-selector reason=Started -w

#Container Resource Limits

Resource limits di Kubernetes mempengaruhi performance secara langsung:

# Resource limits yang mempengaruhi performance
resources:
  limits:
    cpu: "500m"      # 0.5 CPU core
    memory: "256Mi"  # 256 MB RAM
  requests:
    cpu: "250m"
    memory: "128Mi"

Jika CPU limit terlalu rendah, container akan di-throttle — menambah latency. Testing harus dilakukan dengan resource limits yang sama dengan production.

#Testing Managed Services

#Database-as-a-Service

Managed databases (RDS, Cloud SQL, Cloud Firestore) punya karakteristik performance yang berbeda dari self-hosted:

• Connection limits mungkin lebih rendah
• IOPS limits tergantung tier/plan
• Read replicas menambah latency untuk write consistency

#API Gateway Performance

API Gateway (AWS API Gateway, Kong, Traefik) menambah layer tambahan ke request path. Testing harus mengukur dampak gateway terhadap latency.

// k6: test dengan dan tanpa API Gateway
export default function () {
  // Direct API
  const direct = http.get('https://backend.example.com/products');
  // Via API Gateway
  const viaGateway = http.get('https://api.example.com/products');
 
  check(direct, {
    'direct < 100ms': (r) => r.timings.duration < 100,
  });
  check(viaGateway, {
    'gateway < 150ms': (r) => r.timings.duration < 150,
  });
}

#Cloud Cost Optimization

#Performance vs Cost Trade-off

Cloud performance testing harus mempertimbangkan biaya:

#Penutup

Di episode 16 ini kalian telah memahami cloud & serverless performance:

• Cold start: delay inisialisasi serverless; testing dan mitigasi.
• Autoscaling lag: waktu antara spike sampai instance baru available.
• Container performance: startup time dan resource limits.
• Managed services: database-as-a-service dan API gateway testing.
• Cost optimization: performance vs cost trade-off di cloud.

Di episode 17 selanjutnya, kita akan membahas Tuning & Optimization — bagaimana mengoptimasi aplikasi, database, dan infrastruktur berdasarkan hasil performance test. Siapkan profiler kalian!