Belajar Traefik - Performance Tuning

#Pendahuluan

Traefik yang berjalan bukan berarti Traefik yang optimal. Episode 27 membahas performance tuning: bagaimana Traefik memakai sumber daya, parameter yang paling berpengaruh pada latensi dan throughput, serta cara mengukur apakah perubahan benar-benar membantu — bukan sekadar merasa.

Prinsip utamanya: jangan mengoptimasi tanpa mengukur. Kita mulai dari transport connection, masuk ke TLS, lalu membahas middleware, dan ditutup dengan benchmarking yang jujur. Setelah episode ini, kalian bisa memaksimalkan Traefik untuk workload kalian sendiri.

#Resource Optimization

#Memori dan CPU

Traefik ringan, tapi penggunaan memori dipengaruhi beberapa hal:

• Buffering middleware: menampung payload di memori — kurangi memRequestBodyBytes jika memori terbatas.
• Access log buffering: bufferingSize besar menambah footprint memori.
• Koneksi aktif: setiap koneksi memakai memori kecil; koneksi idle yang menumpuk menambah beban.

Alokasikan CPU untuk Traefik secara proporsional: dual-core sudah nyaman untuk ratusan request per detik dengan middleware dasar. Naikkan saat memakai banyak middleware berat atau TLS dengan trafik tinggi.

#Transport Configuration

#ServersTransport untuk Backend

Koneksi Traefik ke backend diatur oleh ServersTransport. Parameter-parameter berikut paling berdampak:

http:
  serversTransports:
    prod:
      maxIdleConnsPerHost: 100
      idleConnTimeout: "90s"
      responseHeaderTimeout: "30s"
      dialTimeout: "5s"
      insecureSkipVerify: false

• maxIdleConnsPerHost: jumlah koneksi idle yang dipertahankan per backend. Nilai tinggi mengurangi biaya pembukaan koneksi baru — efek terbesar untuk trafik burst.
• idleConnTimeout: kapan koneksi idle dianggap basi dan ditutup.
• responseHeaderTimeout: waktu tunggu header response; backend yang lambat mengisi kuota ini lalu koneksi ditutup.
• dialTimeout: batas waktu membuka koneksi baru ke backend.

ServersTransport dihubungkan ke service lewat nama:

http:
  services:
    api-svc:
      loadBalancer:
        servers:
          - url: "http://10.0.0.130:8080"
        serversTransport: prod

#TLS Performance

#Session Resumption dan HTTP/2

TLS handshake adalah operasi paling mahal di proxy — setiap handshake memakan CPU kriptografi. Trik untuk mempercepat:

• TLS session resumption: klien dan server mengingat sesi, sehingga handshake berikutnya lebih singkat. Traefik mendukungnya secara default.
• HTTP/2 multiplexing: banyak request berjalan dalam satu koneksi TCP, mengurangi handshake dan head-of-line blocking di level koneksi. Aktif secara default di entrypoint HTTPS.
• Certificate caching: sertifikat di-cache di memori; pastikan acme.json jarang diakses dari disk.

Untuk trafik TLS super tinggi, pertimbangkan terminasi TLS di load balancer depan dan Traefik menerima trafik internal — trade-off kontrol vs kinerja yang harus kalian nilai sendiri.

#Middleware Optimization

#Strategi Pemasangan

Middleware bisa menjadi beban, jadi pasang dengan sadar:

• Urutan: decision middleware (auth, rate limit) menolak request lebih awal, menghemat kerja middleware lain.
• Compress: kompresi menghabiskan CPU. Jangan kompresi response kecil (atur minResponseBodyBytes) dan file yang sudah terkompresi.
• Buffering: hanya jika dibutuhkan — buffering menambah memori dan latensi.
• Caching: Traefik tidak menyediakan cache response bawaan; untuk aset statis, pasang CDN atau layer cache di depan.

#Benchmarking

#Alat Ukur

Sebelum dan sesudah setiap perubahan, ukur dengan alat yang konsisten:

wrk -t4 -c200 -d30s http://localhost/api

ab -n 10000 -c 100 http://localhost/api

k6 run --vus 100 --duration 30s script.js

Tiga alat dengan karakter berbeda: wrk sangat cepat dan ringan, ab klasik dan ada di mana-mana, k6 berbasis skrip dan cocok untuk skenario kompleks. Perintah wrk dengan 200 koneksi paralel selama 30 detik memberi baseline throughput dan latensi.

#Membaca Hasil

Perhatikan tiga angka: requests/sec (throughput), latency percentiles (p95, p99), dan error rate. Bandingkan baseline dengan hasil setelah tuning — jika p95 turun dan throughput naik, perubahan kalian berhasil. Jika tidak ada perubahan, kalian mungkin menyentuh bottleneck di tempat lain: backend, jaringan, atau CPU.

#Penutup

Inti yang harus dibawa pulang:

• Optimasi dimulai dari ukuran: tanpa baseline, tidak ada arah.
• maxIdleConnsPerHost adalah parameter transport paling berdampak.
• TLS session resumption dan HTTP/2 mengurangi biaya handshake.
• Pasang middleware dengan sadar: decision dulu, transformasi terakhir.
• wrk, ab, dan k6 adalah alat benchmarking standar.
• Bandingkan p95 dan throughput sebelum-sesudah untuk validasi.

Di episode 28 selanjutnya kita akan membahas security hardening — prinsip least privilege, mengamankan dashboard, API, dan endpoint metrics, konfigurasi TLS yang kuat, keamanan container dengan non-root dan read-only filesystem, serta manajemen secret dengan Docker secrets dan Kubernetes secrets.