Anda memiliki sebuah proses yang sedang berjalan, dan satu kelompok permintaan terus mengalami timeout sementara yang lainnya terlihat baik-baik saja. Pemeriksaan iklan berhasil di satu sesi browser, gagal di sesi lainnya, dan pekerjaan pengambilan data hanya melewatkan halaman target ketika kumpulan proxy berputar pada saat yang salah. Itulah jenis kekacauan yang diciptakan oleh latensi, karena masalahnya biasanya bukan satu sampel yang buruk. Ini adalah distribusi yang tersembunyi di balik rata-rata yang terlihat bersih.
Jika Anda mengukur latensi dengan cara yang salah, Anda akan menghabiskan berjam-jam untuk menyetel lapisan yang salah. Permintaan mungkin lambat karena DNS, pengaturan TCP, negosiasi TLS, pemrosesan server, kehilangan paket, atau jalur proxy itu sendiri. Dalam alur kerja seluler dan 4G, IP publik, ASN, dan NAT tingkat operator dapat mengubah bentuk apa yang Anda lihat, jadi jalur yang Anda uji di pusat data tidak akan memberi tahu Anda banyak tentang jalur yang diambil oleh lalu lintas nyata Anda. Tolok ukur yang baik dimulai dengan memperlakukan latensi sebagai kurva, kemudian memecah kurva itu sampai bagian yang lambat menjadi jelas.
Biaya Sebenarnya dari Permintaan yang Lambat
Sebuah proses pengambilan data yang terlihat sehat di atas kertas masih bisa rapuh dalam produksi. Penjadwal pekerjaan melaporkan throughput normal, tetapi beberapa halaman terhenti cukup lama untuk memicu pengulangan, dan seluruh batch selesai terlambat. Dalam verifikasi iklan, pola yang sama muncul sebagai tes yang terlihat baik di browser dengan beban rendah, kemudian mengembalikan hasil yang tidak konsisten ketika jalur jaringan berubah atau proxy berputar di tengah sesi. Dalam kedua kasus, gejala yang terlihat adalah tenggat waktu yang terlewat, tetapi penyebabnya biasanya tersebar di banyak permintaan, bukan satu pemadaman dramatis.
Itulah mengapa rata-rata itu berbahaya. Sebuah layanan dapat memiliki rata-rata yang terhormat dan tetap terasa lambat bagi pengguna karena ekor yang jelek. Jika Anda hanya melihat satu angka ringkasan, Anda akan melewatkan permintaan yang paling lambat, dan itulah yang merusak alur masuk, pemeriksaan yang sensitif terhadap waktu, dan tes yang bergantung pada geo.
Aturan praktis: perlakukan latensi sebagai set sampel, bukan satu pembacaan. Pertanyaan pertama bukanlah “Apa rata-ratanya?” Melainkan “Bagaimana bentuk ekornya, dan apa yang berubah di sana?”
Ketika saya melakukan debugging jalur pengambilan data atau verifikasi, saya mulai dengan bentuk latensi, bukan rata-rata. Median yang bersih dengan p95 atau p99 yang jelek berarti sistem sebagian besar baik-baik saja, tetapi sepotong kecil lalu lintas sedang tertekan oleh kemacetan, pengulangan, atau lompatan yang buruk. Sepotong itu seringkali cukup untuk merusak perilaku produksi.
Untuk tim yang melalui jalur seluler, ini menjadi lebih penting. Jalur 4G dapat terlihat stabil untuk sementara waktu, kemudian berubah karena jaringan, operator, atau status sesi proxy. Itulah mengapa titik referensi yang tepat adalah distribusi penuh, bukan rata-rata yang menenangkan. Jika Anda memerlukan dasar untuk konsep stabilitas jaringan, perhatikan juga konteks operasional yang lebih luas, karena latensi hanyalah satu sisi dari kualitas jalur: referensi stabilitas jaringan.
Dasar-Dasar Latensi yang Anda Butuhkan Sebelum Menguji
Mulailah dengan istilah yang penting
Waktu perjalanan pulang-pergi, RTT, adalah waktu untuk sebuah paket pergi dan kembali. Ini adalah unit dasar yang paling banyak diekspos oleh alat jaringan, dan biasanya diukur dalam milidetik. Penundaan satu arah hanya valid ketika kedua ujung memiliki jam yang disinkronkan dengan ketat, itulah sebabnya sebagian besar tim produksi tetap menggunakan RTT kecuali mereka mengontrol waktu di kedua sisi. Jitter adalah variasi antara pengukuran, kehilangan paket adalah lalu lintas yang hilang, dan throughput adalah seberapa banyak data yang dapat dibawa oleh jalur seiring waktu.
Persentil memberi Anda pandangan praktis. p50 adalah tengah distribusi, p95 menunjukkan level di mana 95% permintaan berada di bawahnya, dan p99 mendorong lebih dalam ke ekor di mana permintaan lambat yang jarang berada. Jika median baik-baik saja tetapi p95 dan p99 membentang, pengguna Anda masih akan merasakannya.
Pikirkan dalam lapisan, bukan dalam satu lompatan
Latensi dimulai di lapisan tautan, tetapi pengguna mengalaminya di lapisan aplikasi. Sebuah paket harus dikirim, diarahkan, diangkut, disusun kembali, dan akhirnya diproses oleh layanan. Itu berarti satu ping hanya dapat memberi tahu Anda sebagian dari cerita, karena itu terutama mengukur jalur, bukan pekerjaan yang dilakukan oleh aplikasi setelah paket tiba.
Model mental yang berguna adalah sederhana. Kualitas jalur fisik mempengaruhi RTT, perilaku transportasi mempengaruhi pengulangan dan pengaturan koneksi, dan pekerjaan aplikasi mempengaruhi berapa lama permintaan menunggu sebelum byte pertama kembali. Itulah sebabnya Anda akan berakhir mengukur di beberapa lapisan jika Anda menginginkan jawaban yang dapat diandalkan.
Jika sebuah tes hanya menunjukkan satu angka, anggap itu tidak lengkap sampai terbukti sebaliknya.
Koneksi 4G seluler menambahkan lapisan variabilitas lainnya. IP publik mungkin berada di belakang NAT tingkat operator, beberapa pengguna dapat berbagi alamat publik yang sama, dan lalu lintas mungkin dikelompokkan berdasarkan konteks ASN daripada berdasarkan jejak residensial yang sederhana. Itu mengubah baik bagaimana tampilan jalur dan bagaimana sistem hilir mengklasifikasikannya, itulah sebabnya pengujian berbasis proxy memerlukan disiplin pengukuran tersendiri.
Mengukur Latensi Dari Baris Perintah
Ping memberi tahu Anda RTT percobaan pertama
Gunakan ping ketika Anda ingin pembacaan cepat tentang kualitas jalur. Perintah sederhana seperti ping -c 20 target memberi Anda set sampel kecil, dan output biasanya diakhiri dengan min/avg/max ditambah nilai sebaran. Bidang latensi yang harus dibaca adalah baris RTT, bukan urutan paket.
Pola output contoh:
20 paket ditransmisikan, 20 diterima, 0% kehilangan paket
rtt min/avg/max/mdev = 12.4/18.7/41.3/6.2 ms
Di sini, avg hanya berguna sebagai orientasi kasar, sementara max menunjukkan ekor. Jika max jauh lebih jelek daripada rata-rata, Anda sudah belajar bahwa jalur tersebut tidak cukup stabil untuk alur kerja yang sensitif.
Traceroute menunjukkan di mana jalur melambat
Gunakan traceroute target ketika Anda memerlukan waktu per lompatan. Angka yang perlu diperhatikan adalah RTT yang ditunjukkan per lompatan, karena di situlah penundaan terakumulasi. Sebuah lompatan yang lambat tidak selalu berarti ada kesalahan, tetapi itu memberi tahu Anda di mana jalur mulai melebar.
Pola output contoh:
1 1.1 ms 1.0 ms 1.2 ms
2 4.8 ms 5.1 ms 4.9 ms
3 19.6 ms 20.1 ms 21.0 ms
Jika lompatan muncul di hop 3 dan tetap tinggi setelah itu, kemungkinan bottleneck berada di hulu target, bukan di dalamnya. Jika lompatan lambat pertama muncul dan lompatan berikutnya pulih, jangan terlalu menginterpretasikannya. Beberapa router mengurangi prioritas balasan probe, yang membuatnya terlihat lambat tanpa merugikan lalu lintas yang sebenarnya.
MTR menggabungkan kedua pandangan
mtr target berguna ketika Anda ingin laporan langsung tentang jalur dan kehilangan. Kolom yang harus dibaca adalah Loss% dan Avg. Sebuah lompatan dengan kehilangan yang meningkat dan RTT rata-rata yang meningkat lebih mengkhawatirkan daripada satu dengan satu lonjakan aneh.
Pola output contoh:
Host Loss% Avg Best Wrst
1 0.0% 1.1 1.0 1.5
2 0.0% 5.0 4.8 5.4
3 2.0% 20.4 19.7 41.2
Perintah ini paling membantu ketika Anda membiarkannya berjalan cukup lama untuk melihat pola daripada lonjakan tunggal. Untuk pekerjaan proxy, itu penting karena jalur yang diputar dapat terlihat baik selama satu menit dan kemudian menyimpang setelah sesi berubah. Jika Anda membangun tolok ukur yang dapat diulang di sekitar kecepatan proxy, jaga sesi tetap stabil dan bandingkan proses dengan baseline tetap, kemudian gunakan alur kerja pemeriksaan kecepatan proxy yang didedikasikan seperti panduan pengujian kecepatan proxy ini.
Iperf3 memberi tahu Anda bagaimana perilaku tautan di bawah beban
Gunakan iperf3 ketika Anda peduli tentang kapasitas dan sensitivitas beban. Perintah dasar seperti iperf3 -c target memeriksa bagaimana jalur berperilaku ketika data mengalir, bukan hanya ketika probe memantul kembali. Bidang yang harus diperhatikan adalah tingkat transfer, karena latensi seringkali memburuk setelah tautan menjadi sibuk.
Pola output contoh:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 120 MBytes 101 Mbits/sec
Itu bukan angka latensi dengan sendirinya, tetapi itu memberi tahu Anda apakah kemacetan kemungkinan akan mempengaruhi waktu permintaan Anda. Jika throughput runtuh di bawah beban, jalur permintaan akan merasakan tekanan itu di suatu tempat.
Tcpdump dan tshark mengungkapkan waktu tingkat paket
tcpdump digunakan untuk menangkap, dan tshark atau Wireshark digunakan untuk analisis. Tangkap aliran, lalu periksa statistik ICMP atau transportasi untuk melihat minimum, maksimum, rata-rata, median, dan deviasi standar. Bidang-bidang tersebut membantu Anda memahami apakah distribusi tersebut ketat atau bising.
Pola tangkapan contoh:
tcpdump -i any host target
Statistik ICMP: min 12 ms, max 71 ms, mean 19 ms, median 16 ms, stddev 8 ms
Itu adalah pandangan yang paling jujur yang akan Anda dapatkan ketika rata-rata ping menyembunyikan bentuk ekor. Ini juga membantu ketika Anda mencurigai bahwa lompatan proxy menambah keterlambatan dengan cara yang tidak dapat dijelaskan dengan jelas oleh alat lompatan demi lompatan.
Latensi Aplikasi dan Browser yang Dapat Anda Lihat
Sebuah permintaan dapat terlihat cepat di lapisan jaringan dan masih terasa lambat di browser. Itulah sebabnya saya selalu memecahnya dengan curl sebelum saya mempercayai hal lain. Bidang yang berguna adalah waktu DNS, waktu koneksi TCP, waktu TLS, TTFB untuk waktu hingga byte pertama, dan waktu total.
Perintah praktis terlihat seperti ini:
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
Contoh output:
dns:0.012 tcp:0.045 tls:0.089 ttfb:0.150 total:0.320
Satu baris itu memberi tahu Anda di mana penantian terjadi. Jika DNS murah tetapi TTFB lambat, server atau jalur proxy adalah masalahnya. Jika TCP dan TLS yang menjadi penghambat, Anda sedang melihat pengaturan koneksi, bukan pengiriman konten.
Gunakan air terjun browser untuk waktu yang terlihat oleh pengguna
DevTools Browser memberi Anda sudut pandang yang berbeda. Panel air terjun Jaringan menunjukkan di mana setiap permintaan menghabiskan waktu, dan tab Waktu membaginya menjadi terhenti, pencarian DNS, koneksi awal, SSL, permintaan terkirim, menunggu (TTFB), dan unduh konten. Pembagian itu penting karena sebuah halaman dapat terlihat rusak bahkan ketika backend sehat.
Jika air terjun menunjukkan sebagian besar penantian sebelum permintaan dikirim, browser atau jalur proxy adalah titik penyumbatan. Jika menunggu mendominasi, backend lambat untuk merespons. Jika unduhan konten adalah tiang panjang, muatannya terlalu berat atau koneksinya terlalu terbatas.
Kebiasaan berguna: bandingkan air terjun browser dengan garis waktu
curldari target yang sama. Jika mereka tidak setuju, jalur browser memiliki overhead tambahan yang tidak terlihat oleh tes CLI Anda.
Monitoring sintetis dan monitoring pengguna nyata memiliki tujuan yang berbeda. Pemeriksaan sintetis terkontrol dan dapat diulang, yang Anda inginkan untuk pengujian regresi. Waktu pengguna nyata menangkap apa yang dialami pengunjung sebenarnya, yang lebih baik untuk menemukan masalah ekor panjang yang hanya muncul di dunia nyata.
Untuk pekerjaan pipeline, jawaban yang paling bersih sering kali adalah menandai waktu kejadian pada pengambilan, pemrosesan, dan penyajian, lalu mengurangi titik-poin yang berdekatan. Pembingkaian berbasis tahap Amplitude untuk waktu kejadian dan definisi latensi data Snowplow keduanya mengarah pada ide yang sama, angka yang berguna sering kali adalah waktu dari satu tahap ke tahap berikutnya, bukan hanya total dari ujung ke ujung. Itu adalah profil latensi yang biasanya dibutuhkan verifikasi iklan dan aliran riset pasar.
Membaca Angka Tanpa Menipu Diri Sendiri
Sebuah rata-rata dapat terlihat sehat sementara pengalaman pengguna sangat buruk. Misalkan sebagian besar permintaan selesai dalam rentang kecil, tetapi beberapa yang lambat meregang jauh. Median mungkin tetap tenang, rata-rata mungkin bergerak hanya sedikit, dan yet orang-orang yang terkena ekor merasa sistemnya rusak.
Baca persentil sebagai bentuk
p50 memberi tahu Anda bagaimana rasanya normal. p95 memberi tahu Anda seberapa jauh ekor umum meregang. p99 memberi tahu Anda apakah rasa sakit yang jarang mulai merayap ke produksi. Ketika p50 tetap datar tetapi p99 naik, sistem menjadi kurang dapat diprediksi meskipun pusat distribusi terlihat baik.
Itu adalah tempat pertama yang saya lihat dalam tolok ukur produksi. Jika p99 jelek, saya berhenti memperlakukan rata-rata sebagai metrik keputusan dan mulai memperlakukannya sebagai sumber kebisingan.
Pisahkan masalah lompatan dari masalah layanan
Lompatan pertama yang lambat dalam traceroute atau MTR biasanya menunjukkan kemacetan jalur, jarak, atau jalur proxy itu sendiri. Lompatan yang hilang dapat menjadi artefak routing, terutama jika lompatan berikutnya tidak menurun dengan cara yang sama. Pencarian DNS yang lambat berarti Anda harus menguji resolusi nama secara terpisah, sementara handshake TLS yang lambat biasanya berarti pengaturan koneksi atau negosiasi sertifikat adalah penghambat. Jika sisi server lambat setelah semua itu, waktu hingga byte pertama akan menunjukkan hal itu.
Alur kerja yang paling aman adalah repetitif, bukan cerdas. Tetapkan baseline, uji di bawah beban, pisahkan berdasarkan waktu dalam sehari dan berdasarkan hari kerja versus akhir pekan, lalu cari kehilangan paket dan lompatan lambat. Satu snapshot dapat berbohong, tetapi pola seiring waktu biasanya tidak.
Untuk verifikasi iklan dan pengambilan data, pekerjaan dimulai di sini. Jalur yang dapat diterima di jam-jam sepi mungkin menjadi tidak stabil setelah penyedia atau jalur hulu berubah. Jika jalur berubah di tengah pengujian, persentil Anda berhenti menggambarkan satu sistem dan mulai menggambarkan beberapa yang berbeda.
Mengukur Latensi Melalui Proxy Seluler dan 4G
Sebuah permintaan dapat terlihat cepat dari pusat data dan masih terasa lambat setelah meninggalkan jaringan seluler. ASN mengubah gambaran sebelum paket mencapai target Anda, karena itu menunjukkan jaringan mana yang memiliki alamat dan jalur hulu mana yang sebenarnya Anda uji. Carrier-grade NAT mengubahnya lagi, karena IP publik yang dibagikan dapat menyembunyikan kontensi tambahan dan membuat permintaan yang sama berperilaku berbeda dari satu kali ke kali berikutnya.
Itulah mengapa tolok ukur harus tetap terikat pada satu jalur. Jika Anda memutar IP proxy saat mengumpulkan sampel, Anda berhenti mengukur satu koneksi dan mulai mencampur beberapa jalur menjadi satu set persentil. Pertahankan sesi lengket yang sama sepanjang pengujian, lalu ulangi tes setelah rotasi jika Anda ingin melihat seberapa banyak jalur itu sendiri berubah. Untuk catatan pengaturan yang lebih dalam tentang routing seluler, panduan proxy 4G LTE ini adalah tempat yang paling jelas untuk memeriksa perilaku sesi yang perlu Anda pertahankan.
Apa yang harus dijaga tetap konstan selama pengujian
- Jaga sesi tetap stabil: Jangan memutar IP saat Anda mengumpulkan sampel latensi. Satu perubahan jalur dapat menggeser distribusi cukup untuk membuat tolok ukur sulit dibaca.
- Periksa ASN terlebih dahulu: Konfirmasi apakah jalur berada di jaringan seluler, jalur residensial, atau jalur pusat data sebelum Anda membandingkan hasil.
- Gunakan endpoint yang sama dan jendela waktu yang sama: Jika tidak, Anda mencampur perubahan jaringan dengan perubahan beban kerja, dan hasilnya berhenti berguna.
- Bandingkan yang sebanding: Jalankan permintaan yang sama dari asal, lalu melalui proxy residensial, lalu melalui proxy seluler 4G.
Perbandingan terakhir itu adalah yang paling mendekati perilaku produksi. Jalur seluler dengan sesi yang stabil memberi Anda pandangan yang lebih bersih tentang apa yang akan dilihat verifikasi iklan atau lalu lintas pengambilan, sementara sesi yang berputar memberi tahu Anda lebih banyak tentang churn daripada latensi.
Mengapa traceroute dapat terlihat aneh di 4G
Jalur 4G jarang terlihat seperti jalur perusahaan yang bersih. Beberapa lompatan tidak pernah menjawab, beberapa balasan dibatasi, dan IP publik mungkin berada di belakang tepi penyedia alih-alih satu mesin tunggal. Traceroute masih membantu, tetapi anggap itu sebagai cara untuk membaca bentuk jalur, bukan sebagai peta sempurna dari setiap lompatan.
Kebiasaan operasional yang tetap sederhana. Benchmark tiga jalur berdampingan, jaringan asal Anda, permintaan yang sama melalui proxy residensial, lalu permintaan yang sama melalui proxy seluler 4G. Pertahankan sesi tetap di setiap kasus, lalu bandingkan p50, p95, p99, dan maksimum. Itu memberi Anda pembacaan praktis tentang latensi sebelum lalu lintas produksi melakukannya.
Jebakan Umum dan Daftar Periksa yang Dapat Anda Gunakan Kembali
- Menguji hanya di jaringan yang tidak aktif. Angka-angka dapat terlihat bersih di jalur yang sepi dan hancur begitu lalu lintas nyata berbagi tautan. Masalahnya bukan pada pengujian itu sendiri, tetapi pada keadaan jaringan selama pengujian. Perbaikan: ulangi pengujian selama periode sibuk dan bandingkan pergeseran distribusi.
- Mengambil satu jendela sampel. Satu pengujian singkat dapat terlihat konklusif meskipun masih sulit untuk diulang. Masalahnya adalah kebisingan waktu dan jalur yang berubah di bawah Anda. Perbaikan: kumpulkan beberapa jendela dan bandingkan penyebarannya, bukan hanya angka utama.
- Mengabaikan latensi ekor. Rata-rata yang sehat dapat menyembunyikan permintaan lambat yang dirasakan pengguna. Masalah ini muncul di ujung jauh distribusi, bukan di tengah. Perbaikan: baca p95, p99, dan maksimum bersama-sama, lalu putuskan apakah ekor tersebut dapat diterima.
- Memutar proxy di tengah pengujian. Jika sesi berubah di tengah jalan, rute juga berubah dan persentil berhenti berarti banyak. Itu umum terjadi pada jalur seluler dengan NAT kelas operator dan perilaku sesi yang lengket, di mana satu pengujian mungkin tetap di satu keluar dan yang berikutnya mungkin tidak. Perbaikan: pertahankan satu sesi lengket untuk seluruh pengujian.
- Hanya mengukur server. Pencarian DNS yang lambat atau penundaan dalam handshake TLS dapat disalahkan pada backend meskipun aplikasi bukanlah penyebab kemacetan. Penghitung harus memisahkan pengaturan koneksi, waktu handshake, dan waktu respons. Perbaikan: pisahkan permintaan menjadi tahap-tahap tersebut dan catat masing-masing.
- Menggunakan rata-rata untuk pelaporan. Rata-rata dapat meratakan pengalaman pengguna yang buruk menjadi angka yang terlihat tidak berbahaya. Itu menyembunyikan permintaan yang gagal dalam pengambilan data, pemeriksaan verifikasi iklan, atau alur QA seluler. Perbaikan: laporkan persentil yang sesuai dengan permintaan nyata dan pertahankan maksimum mentah dalam pandangan.
- Mematikan sebelum permintaan yang sedang diproses selesai. Pengujian yang berakhir terlalu awal dapat melewatkan permintaan yang paling lambat dan membuat tolok ukur terlihat lebih baik daripada yang sebenarnya. Jendela pengumpulan tidak lengkap, sehingga maksimum dinyatakan lebih rendah. Perbaikan: biarkan tolok ukur mengalir sebelum Anda menghentikannya.
Untuk alur kerja proxy seluler dan 4G, daftar periksa sangat sederhana. Konfirmasikan ASN dan perilaku sesi sebelum Anda membandingkan hasil, pegang titik akhir dan jendela waktu dengan stabil, kumpulkan cukup sampel untuk melihat ekor, dan verifikasi bahwa keanehan traceroute diharapkan untuk jalur operator yang Anda gunakan. Jika Anda memerlukan referensi untuk perilaku proxy 4G dan LTE, gunakan halaman wiki yang sudah Anda simpan untuk pengaturan itu, lalu uji terhadap dasar Anda sendiri daripada mengasumsikan satu jalur akan berperilaku seperti jalur lainnya.
