Belajar Network Engineer - Network Performance & Optimization

#Pendahuluan

Setelah di episode 23 desain kalian tahan gagal, keluhan berikutnya lebih halus namun lebih sering: "jaringannya lambat". Kalimat itu bukan data — ia perasaan. Tugas engineer adalah menerjemahkannya menjadi angka terukur, mencari titik kemacetan, dan membuktikan perbaikannya dengan pengukuran sebelum-sesudah. Tanpa metodologi, optimasi hanyalah mitos yang diturunkan.

Episode ini adalah toolkit performa kalian: definisi metrik, baseline, alat ukur, teori yang menjelaskan gejala aneh, dan playbook audit.

#Empat Metrik yang Mendefinisikan "Cepat"

Semua diskusi performa bermuara ke empat besaran — hafalkan definisi DAN target umumnya:

Poin filosofis penting: latency punya batas fisika — cahaya di serat ±5 µs/km; Jakarta–Singapura ~900 km berarti RTT teoretis ≥9 ms sebelum satu router pun menambah delay. Engineer hebat tahu kapan masalahnya fisika, bukan konfigurasi — dan berhenti mengejar mustahil.

#Baseline: Angka Sebelum Masalah

Prinsip dari episode 10 layak diulang dalam konteks performa: tanpa baseline, kalian tidak akan pernah tahu apakah jaringan memburuk atau memang begitu dari awal. Baseline minimal:

• Utilization per link jam kerja vs malam (pola harian + pekanan).
• RTT antar site pada jam tenang vs puncak.
• Error counter interface (CRC, drops) tren bulanan.
• Throughput uji iperf3 antar segmen kunci tiap kuartal.

Simpan sebagai spreadsheet/dashboard dengan tanggal — saat insiden datang, pertanyaan "kapan mulai buruk?" terjawab dalam menit, bukan minggu debat.

#Toolkit Pengukuran

#iperf3: Kebenaran Throughput

Uji dua arah antara server dan client di jalur yang dicurigai:

iperf3 -s                          # di mesin sisi lain
iperf3 -c 192.168.2.80 -t 30       # TCP 30 detik
iperf3 -c 192.168.2.80 -u -b 100M  # UDP 100 Mbps + jitter/loss

Interpretasi hasilnya yang seni:

• TCP single-stream rendah tapi parallel (-P 4) tinggi → indikasi window size atau latency tinggi, bukan bandwidth kurang.
• UDP loss melonjak sebelum target → antrian/policer di tengah jalur.
• Hasil beda arah A→B vs B→A → asimetri link/policy (ingat pitfall episode 23).

#mtr: Peta Latency yang Hidup

mtr menggabungkan traceroute + ping kontinu per hop:

mtr -rwzc 100 203.0.113.50     # 100 siklus, report wide

Kolom yang dibaca: Loss% dan stdev kolom Avg/Best/Wrst. Trik interpretasi klasik: hop tengah menunjukkan loss tapi hop akhir bersih → hop itu hanya deprioritaskan ICMP (bukan masalah). Loss yang bertahan sampai hop akhir → benar-benar bermasalah di sana.

#tcpdump/Wireshark: Hakim Banding

Saat angka agregat tak cukup, paket-level bicara: retransmit TCP beruntun, zero window, dup ACK, RST mendadak. Filter investigasi cepat:

tcpdump -ni eth0 'tcp[tcpflags] & (tcp-rst) != 0'      # siapa me-RST?
tcpdump -ni eth0 host 10.40.1.20 and port 443 -w cap.pcap

#Teori yang Menjelaskan Gejala Nyata

#Bandwidth-Delay Product (BDP)

Throughput TCP maksimum = window size / RTT. Konsekuensi mengejutkan: link 1 Gbps dengan RTT 60 ms butuh window ±7.5 MB agar penuh! Satu stream dengan window 256 KB akan mentok di ±34 Mbps — dan user menyalahkan "bandwidth kurang". Ini juga penjelasan kenapa iperf3 multi-stream lebih cepat: lebih banyak data in-flight.

#Bufferbloat

Buffer besar di perangkat murah menahan paket ratusan milidetik saat link penuh: throughput bagus di speedtest, tapi latency meledak persis saat dipakai (video call rusak saat backup jalan). Solusinya QoS episode 11 (FQ-CoDel/AQM) — bukan upgrade bandwidth buta.

#Queueing di Bottleneck

Paket yang jatuh selalu jatuh di titik sempit — temukan dia dengan menghitung kapasitas tiap hop di jalur (interface counters + baseline), bukan menebak dari gejala di ujung.

#Daftar Penyebab Lambat Paling Umum

Dari lapangan, delapan biang keladi ini menjawab mayoritas tiket "lambat":

1. Duplex/speed mismatch di salah satu ujung (negosiasi manual) — CRC error merambat.
2. Interface error naik (kabel/connector/SFP tua) — cek show interfaces counter dulu, selalu.
3. Link saturasi pada jam tertentu (baseline menunjukkannya).
4. CPU perangkat tinggi — forwarding ke CPU (punt) karena fitur tak offload.
5. MTU/fragmentasi di jalur tunnel — transfer besar macet, ping lancar (episode 19!).
6. Asymmetric routing membuat state/firewall/proxy hanya melihat setengah trafik.
7. Server-side sebenarnya — database/query; jaringan difitnah. Bukti: RTT jaringan bersih, waktu respons aplikasi tetap buruk.
8. Client-side: Wi-Fi sinyal lemah/rate lambat (episode 7) atau driver NIC lawas.

#Praktik: Playbook Audit Performa End-to-End

Rangkaian kerja formal saat kalian ditugaskan "perbaiki performa cabang Surabaya":

[1] Definisi sukses : tulis target angkat (mis. ERP response < 200 ms p95)
[2] Baseline        : mtr + iperf3 + util link, jam tenang & puncak, catat semua
[3] Localize        : bandingkan segmen (LAN HQ? WAN? LAN SBY? server?)
    - iperf3 intra-LAN SBY   : normal? -> LAN bersalah jika tidak
    - iperf3 lintas-WAN      : sesuai kontrak? BDP check
    - app test end-to-end    : beda dengan iperf3? -> server-side suspect
[4] Perangkat       : error/CPU/queue-drop counters di tiap hop kunci
[5] Hipotesis       : satu penyebab utama dari daftar 8 di atas
[6] Intervensi      : SATU perubahan (fix duplex / tambah stream / QoS / MTU)
[7] Re-measure      : ulangi langkah 2, bandingkan tabel before-after
[8] Dokumentasikan  : laporan singkat angka + root cause + preventif

Langkah 7 yang membedakan profesional dari pendengar cerita: tabel before-after dengan angka sama metodenya. Dan langkah 8 menghubungkan pekerjaan ini ke sistem dokumentasi episode 25 — performa yang diperbaiki tanpa dicatat akan rusak lagi oleh orang berikutnya.

#Common Pitfalls

• Menguji lewat produksi peak tanpa isolasi — hasil iperf3 kalian berebut dengan trafik bisnis; gunakan maintenance window atau QoS class khusus uji.
• Satu tool sebagai kebenaran tunggal — speedtest internet ≠ kondisi internal; triangulasi iperf3 + mtr + counter perangkat.
• Upgrade bandwidth untuk masalah latency — BDP justru memburuk; identifikasi jenis bottleneck dulu (bandwidth vs RTT vs loss).
• Melupakan jam — performa jam 09.00 dan 03.00 bisa beda dunia; ukur kedua-duanya sebelum menyimpulkan.

#Penutup

Inti yang harus dibawa pulang:

• Terjemahkan keluhan ke empat metrik: latency, jitter, loss, throughput — masing-masing punya target dan penyakit khasnya.
• Baseline menjawab "apakah ini memburuk?"; tanpa dia, semua klaim performa adalah opini.
• Alat inti: iperf3 (throughput, multi-stream untuk BDP), mtr (localize hop bermasalah), tcpdump/Wireshark (hakim banding).
• Teori penjelas: BDP (window/RTT membatasi single-stream), bufferbloat (latency naik saat load), bottleneck queue.
• Playbook audit: ukur → localize → jelaskan → ubah satu variabel → ukur ulang → dokumentasikan.

Di episode 25 kita rapikan semuanya menjadi profesi: network design & documentation — requirement gathering, logical vs physical design, standar diagram, NetBox sebagai source of truth, runbook, dan proyek desain lengkap sebagai portofolio kalian. Sampai jumpa!