Belajar Floci - Performance Tuning & Resource Budgeting

#Pendahuluan

Klaim performa Floci sudah kita sebut sepanjang series; episode ini mengujinya dengan angka dan mengajari kalian mengelola angka itu dalam konteks nyata: berapa budget resource untuk runner CI, opsi JVM mana yang masuk akal diubah, dan satu risiko keamanan yang wajib dipahami siapa pun yang mem-mount docker.sock.

#Angka Kunci

#Benchmark Resmi & Interpretasinya

Cara membaca angka ini secara dewasa:

• Startup 138x terasa paling besar di CI: service container + health check yang tadinya makan 5–30 detik per job kini praktis gratis.
• Idle RAM 11x menentukan berapa banyak job paralel yang muat di satu runner self-hosted.
• Image 90 MB mempercepat cold pull di runner baru — sering kali komponen paling dominan dari durasi job.

Verifikasi sendiri di laptop kalian:

time docker run --rm -d --name perf -p 4566:4566 floci/floci:1.5.15
curl -sf http://localhost:4566/_floci/health >/dev/null && echo ready
docker stats perf --no-stream --format '{{.MemUsage}}' # RAM idle aktual
docker images floci/floci --format '{{.Size}}'
docker rm -f perf >/dev/null

#Optimasi

#Mode Storage untuk Kecepatan

Dari episode 15: mode memory adalah pilihan tercepat dan default ideal untuk CI. Aturan alokasinya:

CI / unit test      -> memory        (tercepat, volatile - state tak dibutuhkan)
Dev harian          -> persistent    (flush async 5s, cukup aman)
Eksperimen zero-loss-> WAL           (biaya write tertinggi)

#JVM Options

Floci berjalan di JVM — dan JVM modern cerdas soal memori, tapi ada dua tuas yang berguna:

environment:
  JAVA_TOOL_OPTIONS: "-XX:+UseSerialGC -Xmx256m" # heap cap utk runner kecil

• -XX:+UseSerialGC — untuk workload kecil/serentak rendah, GC serial lebih hemat CPU daripada collector paralel.
• -Xmx — batasi heap agar beberapa instance bisa hidup bersama di runner yang sama. Jangan set terlalu kecil saat dataset test besar (bulk import DynamoDB dsb.).

Ukur dampaknya, jangan tebak: bandingkan docker stats dan durasi suite dengan/tanpa flag.

#Docker Sock Host Limits & Pull Policy CI

Untuk layanan container (episode 12), kendalikan dampaknya ke host:

# RDS/ECS yang di-spawn floci adalah container biasa -
# batasi lewat spec saat create:
aws rds create-db-instance ... --max-allocatable-storage 20
# dan kelola disk runner:
docker system df && docker system prune -f --volumes # housekeeping berkala

Pull policy di CI: gunakan image pinned sehingga cache runner efektif; hindari --pull always kecuali sengaja upgrade.

#Keamanan

#Risiko Mounting docker.sock di Shared Runner

Mount /var/run/docker.sock memberi floci akses API penuh ke Docker Engine host — setara root-ish pada host tersebut. Di laptop developer itu trade-off wajar; di shared runner ia menjadi permukaan serangan:

• Proses di dalam container bisa spawn/hapus container arbitrer, baca volume lain, atau eksekusi privileged container.
• Job PR dari fork publik + docker.sock = kombinasi berbahaya (untrusted code menyentuh socket).

Mitigasi berlapis:

[x] Jangan mount docker.sock untuk job yang menjalankan kode untrusted (fork PR)
[x] Pisahkan job integration (butuh sock) dari job lint/unit di workflow beda
[x] Self-hosted runner: jalankan di user khusus + audit plugin Docker
[x] Alternatif: gVisor/Kata runtime isolation bila organisasi mensyaratkannya
[x] Hapus sock dari compose dev ketika hanya pakai layanan in-process

#Praktik

Target outline: ukur & optimalkan waktu CI sebelum/sesudah floci.

#!/usr/bin/env bash
set -euo pipefail
IMG=${1:-floci/floci:1.5.15}
 
T0=$(date +%s%3N)
docker run --rm -d --name cb -p 4567:4566 "$IMG" >/dev/null
for i in $(seq 1 100); do curl -sf http://localhost:4567/_floci/health >/dev/null && break || sleep 0.05; done
T1=$(date +%s%3N)
echo "startup+ready : $((T1-T0)) ms"
 
export AWS_ENDPOINT_URL=http://localhost:4567
S=$(date +%s%3N)
for i in $(seq 1 100); do aws sqs create-queue --queue-name q$i >/dev/null; done
E=$(date +%s%3N)
echo "100 create-queue: $((E-S)) ms ($(( (E-S)/100 )) ms/op)"
 
docker stats cb --no-stream --format 'mem idle: {{.MemUsage}}'
docker rm -f cb >/dev/null

Catat tiga metrik ini di README tim (startup+ready, throughput operasi, idle mem) dan pantau antar versi floci — regresi performa emulator akan ketahuan sebelum merusak pipeline.

#Penutup

Rangkuman episode ini:

• Angka kunci: 24 ms startup (138x), 13 MiB idle RAM (11x), 90 MB image — verifikasi dengan docker stats, jangan percaya klaim buta.
• Optimasi: memory mode untuk CI, JVM flags hemat (SerialGC, heap cap), housekeeping container turunan, pull policy bijak.
• Keamanan: docker.sock = akses penuh engine host; pisahkan job untrusted, pertimbangkan runtime isolation.

Episode 25 melebarkan pandangan: perbandingan ekosistem emulator — floci vs LocalStack paid vs MiniStack vs Moto vs SAM CLI, plus limitasi jujur Floci. Sampai jumpa!