89. Performance Benchmarking dengan ghz — Panduan Lengkap untuk Mengukur gRPC

Performance benchmarking mungkin terdengar seperti kerjaan tim QA atau SRE, tapi bagi saya—seorang developer—memahami dan menerapkan benchmark adalah bagian vital dalam membangun sistem yang scalable. Apalagi ketika bekerja dengan gRPC, framework RPC modern yang banyak diadopsi berbagai perusahaan untuk microservices. Salah satu tool favorit saya adalah ghz, sebuah benchmarker open-source khusus untuk gRPC. Di artikel ke-89 serial ini, saya akan membahas habis soal benchmarking dengan ghz, mengenalkan skenario penggunaan, serta menampilkan contoh real yang bisa langsung kamu adaptasi.

Mengapa Butuh Benchmarking gRPC?

Sebelum masuk ke teknis, mari kita sepakat soal motivasi:

• gRPC mengandalkan komunikasi bersifat high-performance binary (Protocol Buffers), yang berbeda dari REST/JSON.
• Requirement SLA/SLI seperti latency dan throughput sangat krusial dalam microservices, terutama sistem real-time.
• Seringkali terdapat kasus bottleneck di servis servis tertentu—entah di sidecar, network, atau pada prosesor data.
• Tanpa benchmark yang terukur, scaling dan tuning jadi “main perasaan”.

Dengan tool seperti ghz, kamu bisa melakukan simulasi traffic, mengukur response time, menilai RPS yang mampu ditangani oleh servis, hingga menghasilkan laporan benchmark yang mudah dianalisa.

Apa Itu ghz?

Pertama, ghz bukan bagian dari gRPC core ataupun dari tooling official Google. Ini proyek open-source yang ditulis dengan Go, dan saat ini merupakan salah satu tool de-facto untuk benchmarking gRPC.

Feature utama:

• Bisa benchmarking unary dan streaming gRPC endpoint (client-side dan bidirectional).
• Mendukung custom metadata, TLS, headers, hingga autentikasi.
• Beragam output: CLI, JSON, HTML, hingga grafana dashboard.
• Gampang di-automatiskan via script CI/CD.

Instalasi dan Persiapan

go install github.com/bojand/ghz/cmd/ghz@latest

Atau tinggal download binary release dari GitHub Release.

Pastikan juga kamu sudah menginstall service/protobuf client untuk endpoint yang akan diuji. Misal, kita punya proto berikut:

// helloworld.proto
syntax = "proto3";
package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Dan sudah ada server gRPC yang running di localhost:50051.

Contoh Benchmark Dasar

Mari kita lakukan benchmarking endpoint SayHello!

ghz --insecure \
    --proto ./helloworld.proto \
    --call helloworld.Greeter.SayHello \
    --data '{"name":"Medium Reader"}' \
    -c 50 -n 10000 \
    localhost:50051

Keterangan:

• –insecure: Tidak pakai TLS.
• –proto: Lokasi file proto.
• –call: Full qualified method.
• –data: Payload request.
• -c 50: 50 concurrent connections.
• -n 10000: 10.000 request total.

Hasil Benchmark — Analisis Awal

Outputnya cukup komprehensif. Contoh (disingkat):

Summary:
  Count:     10000
  Total:     2.33 secs
  Slowest:   0.0121 secs
  Fastest:   0.0003 secs
  Average:   0.0052 secs
  Requests/sec: 4296.75

Status code distribution:
  [OK]   10000 responses (100.00%)

Insight yang bisa diambil:

Metode Simulasi: Contoh Advance

Misal kita ingin menguji dengan skenario user berbeda, data random, dan custom header (misal, JWT):

1. Buat file input multiple data:

[
  {"name": "UserA"},
  {"name": "UserB"},
  {"name": "UserC"}
]

Simpan sebagai data.json.

2. Use custom header & token

ghz --insecure \
    --proto ./helloworld.proto \
    --call helloworld.Greeter.SayHello \
    --data-file ./data.json \
    -c 100 -n 50000 \
    --metadata "authorization=Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" \
    localhost:50051

Diagram Alur Kerja ghz (Mermaid)

flowchart TD
    A[Start ghz CLI] --> B[Load proto + Data]
    B --> C[Initiate N concurrent client(s)]
    C --> D[Generate and Send Requests]
    D --> E[Measure Response & Gather Metrics]
    E --> F[Aggregate Results]
    F --> G[Print / Export Report]

Membaca Hasil Report & What’s Next?

Selain command-line summary, kamu juga bisa generate HTML report:

ghz --insecure \
    ...[param lain seperti di atas] \
    -O report.html

Contoh ringkasan tabel yang penting diperhatikan:

Analisis:

• Latency P99 sangat penting pada sistem real-time/high concurrency.
• Jika P99 jauh membengkak dibanding rata-rata (mean), mungkin ada masalah “long tail”/outlier.
• Gunakan data ini untuk:
  • Tuning thread/connection pool.
  • Scaling instance.
  • Perbaiki jalur IO atau DB downstream yang bermasalah.

Integrasi dengan CI/CD

ghz cocok diintegrasikan ke pipeline CI/CD:

• Pastikan service gRPC sudah running di background (pakai Docker Compose/k8s job).
• Jalankan benchmark di stage metrics atau regression (bisa sebagai smoke test).
• Parse output JSON dan trigger alert di pipeline jika P99 latency/melebihi threshold.
• Simpan report ke object storage untuk historical comparison.

Useful Tips

• Uji endpoint yang berbeda, bukan hanya “happy path”.
• Simulasikan spike (stress test, pakai thread/concurrency jauh lebih besar dari biasanya).
• Cek impact pada resource server (CPU/mem), dan korelasikan dengan hasil benchmark.
• Tweak parameter grpc server/client (maxConcurrentStreams, connection pooling, dsb).

Kesimpulan

Di era microservices dan cloud-native, benchmarking adalah investasi yang tidak bisa ditawar. Dengan ghz, kita punya tool ringan, powerful, dan mudah diintegrasikan untuk menguji performa real gRPC service.

Ingat, What you don’t measure, you can’t improve.

Selamat mencoba, sampai jumpa di artikel selanjutnya!