Hitung kebutuhan server
Request per detik, ukuran payload, penyimpanan, dan bandwidth. Semuanya pakai satuan, lalu dibandingin sama kapasitas yang kamu punya.
Pertanyaan
Berapa resource yang dibutuhin beban kerja ini, dan sejauh apa dari kapasitas yang ada?
Setelah baca ini, kamu bisa ngisi tabel kebutuhan-versus-kapasitas buat empat komponen, lalu nunjuk mana yang paling deket ke batas.
Prasyarat dan contoh
Kamu sudah bisa nyebut beban kerja dalam request puncak per detik dan rasio baca/tulis (M01.02). Aritmetika dasar dan konversi satuan juga sudah cukup.
Contoh yang sering nipu: tim ngitung "2 juta request per hari, berarti butuh 23 request/detik". Angka itu bener buat rata-rata, tapi hampir nggak berguna buat kapasitas. Puncaknya 8×, dan tiap tulisan jadi dua query. Kebutuhan aslinya bisa hampir sepuluh kali angka pertama.
Mekanisme
Perkiraan yang bagus selalu punya tiga bagian: input dengan satuan, rumus, dan hasil dengan satuan yang sama. Jangan pernah nulis angka telanjang.
1. Laju request.
rpsRataRata = request per hari / 86.400
rpsPuncak = rpsRataRata × pengali puncak
86.400 itu jumlah detik dalam sehari. Pengali puncaknya dari M01.02.
2. Beban basis data. Satu request belum tentu satu query. Asumsi yang harus ditulis: satu baca sama dengan satu query, satu tulis sama dengan dua query (nulis baris plus update indeks).
queryRps = rpsPuncak × rasioBaca + rpsPuncak × (1 − rasioBaca) × 2
3. Transfer jaringan. Ukuran respons dikali laju, lalu dikonversi dari kilobyte ke megabit. Satu byte itu 8 bit; satu megabit 1024 kilobit di konvensi yang dipakai di sini.
egressMbps = rpsPuncak × ukuranResponsKb × 8 / 1024
4. Penyimpanan. Cuma tulisan yang nambah data. Retensi nentuin berapa lama data itu nyimpen.
tulisanPerHari = request per hari × (1 − rasioBaca)
penyimpananGb = tulisanPerHari × retensiHari × ukuranTulisKb / 1.048.576
5. Bandingin. Buat tiap komponen, hitung utilisasi = kebutuhan / kapasitas. Yang
utilisasinya paling tinggi itu pembatas pertama. Ini angka yang nentuin langkah berikutnya, bukan
total request.
Hasil ini bergantung sama asumsi. Ganti satu tulis jadi tiga query, beban basis data naik 50%, tapi kesimpulannya nggak berubah. Perkiraan yang bagus cukup akurat buat ambil keputusan, bukan buat prediksi presisi.
Saat rancangan ini gagal
- Salah satuan. Ngitung kilobyte sebagai kilobit bikin kebutuhan bandwidth delapan kali lebih kecil. Tulis satuan di tiap baris.
- Lupa biaya turunan. Penyimpanan bukan cuma baris data: ada indeks, replika, tombstone, dan overhead filesystem. Kalikan pakai faktor yang kamu tulis, misalnya 1,5 sampai 2×.
- Anggap payload semuanya sama. Halaman daftar dan endpoint redirect ukurannya beda. Rata- ratakan per jenis request.
- Abaikan pertumbuhan. Retensi 365 hari kelihatan aman sampai volume tulisan naik 4×. Hitung juga skenario tumbuh, bukan cuma hari ini.
- Anggap kapasitas linear. Dua kali CPU belum tentu dua kali throughput. Query yang rebutan lock bisa bikin throughput turun pas konkurensi naik.
Contoh tandingan: hitungan bilang basis data cuma kepakai 0,2%, tapi p99 latensinya jelek. Penyebabnya bukan kapasitas, tapi satu query tanpa indeks. Nambah kapasitas nggak bakal nolong; perbaikannya ada di M04.
Latihan
Hitung kebutuhan buat kasus ini: 2 juta request/hari, puncak 2×, respons 1 KB, tulis 8 KB, 40% baca, retensi 3.650 hari. Kapasitas: aplikasi 1.000 req/detik, basis data 2.000 query/detik, bandwidth 500 Mbit/detik, penyimpanan 5.000 GB.
- Hitung keempat kebutuhan.
- Tentukan pembatas pertama.
- Sebut satu asumsi yang paling ngubah kesimpulan.
Lihat pembahasan
rpsRataRata = 2.000.000 / 86.400 ≈ 23,1 req/detik
rpsPuncak = 23,1 × 2 ≈ 46,3 req/detik
queryRps = 46,3 × 0,4 + 46,3 × 0,6 × 2 ≈ 74,1 query/detik
egressMbps = 46,3 × 1 × 8 / 1024 ≈ 0,36 Mbit/detik
tulisan/hari = 2.000.000 × 0,6 = 1.200.000
penyimpananGb = 1.200.000 × 3.650 × 8 / 1.048.576 ≈ 33.400 GB
Utilisasi: aplikasi 4,6%; basis data 3,7%; bandwidth 0,07%; penyimpanan 668%. Pembatas pertamanya penyimpanan, dan komponen itu udah lewat kapasitas.
Asumsi yang paling ngaruh: ukuran record tulis 8 KB dan retensi sepuluh tahun. Gandain salah satunya, kebutuhan penyimpanan ikut dua kali. Asumsi kedua yang penting: satu tulisan cuma dua query. Kalau ada indeks tambahan, beban basis datanya naik.
Terkait
- Lab L01 ngitung rumus yang sama secara interaktif. Coba skenario "arsip tulis berat" dan bandingin sama jawabanmu.
- M01.04 Pasang target yang masuk akal bahas kapan utilisasi 60% masih aman dan kapan nggak.
- M04.03 Rancang indeks jelasin biaya query yang diasumsikan di sini.
Catatan
- Asumsi: satu tulis sama dengan dua query; egress cuma badan respons; penyimpanan belum termasuk replika dan indeks.
- Model ini nggak ngitung antrean, cache, kompresi, CDN, atau burst mikro.
- Konvensi: 1 GB = 1.048.576 KB; 1 Mbit = 1024 Kbit.
- Terakhir ditinjau: 25 Oktober 2026.