Mengukur latensi dengan benar mengharuskan Anda memiliki data yang berkualitas. Global CEO Outlook 2016 KPMG (tautan berada di luar ibm.com) menemukan bahwa 84% CEO mengkhawatirkan kualitas data yang menjadi dasar keputusan mereka dan itu karena data sering kali dapat menyesatkan.
Perbedaan antara perusahaan yang peduli dengan data mereka dan tidak sangat besar. Peneliti MIT menemukan (tautan berada di luar ibm.com) bahwa perusahaan yang telah mengadopsi desain berbasis data memiliki output 5% - 6% lebih tinggi dari apa yang diharapkan mengingat investasi mereka yang lain dan penggunaan teknologi informasi. Alasan ini saja membuat pemahaman latensi penting untuk kesuksesan bisnis.
Hanya dalam tujuh menit, Anda akan mempelajari semua yang perlu Anda ketahui tentang mengukur latensi:
Dictionary.com (tautan berada di luar ibm.com) mendefinisikan latensi sebagai “periode penundaan ketika satu komponen sistem perangkat keras menunggu tindakan untuk dijalankan oleh komponen lain.” Dalam istilah yang lebih sederhana, ini berarti jumlah waktu antara memanggil fungsi dan eksekusi aktualnya. Latensi melekat pada semua sistem; bahkan jika kita memiliki sistem yang sempurna, yang tentu saja tidak ada, itu akan menjadi jumlah waktu laten yang dibutuhkan elektron dalam komputer untuk mengalihkan transistor dari aktif ke nonaktif atau sebaliknya.
Latensi dalam operasi kecil bukanlah masalah besar, tetapi ketika menangani jutaan operasi, ada jutaan latensi yang bertambah dengan cepat. Latensi tidak ditentukan oleh unit kerja dan waktu tetapi, sebaliknya, bagaimana perilakunya. Alat pemantauan melaporkan kembali berapa lama waktu yang dibutuhkan dari awal fungsi hingga akhir fungsi.
Latensi dapat berdampak besar pada bisnis Anda. Misalnya (tautan berada di luar ibm.com): “Ketika menyangkut kecepatan mobile, setiap detik penting — untuk setiap detik tambahan yang dibutuhkan halaman mobile untuk dimuat, konversi dapat turun hingga 20%.”
Latensi hampir tidak pernah mengikuti distribusi Gaussian atau Poisson normal. Bahkan jika latensi Anda mengikuti salah satu distribusi ini, karena cara kami mengamati latensi, itu membuat rata-rata, median, dan bahkan standar deviasi tidak berguna.Jika, misalnya, Anda mengukur pemuatan halaman, 99,9999999999% dari beban ini mungkin lebih buruk daripada median Anda. Ini adalah bagian dari alasan mengapa pengambilan sampel latensi secara acak menyebabkan data yang tidak akurat—tetapi akan membahas topik ini nanti.
Pada titik ini, Anda mungkin bertanya pada diri sendiri, jika kita tidak menggunakan deviasi standar apa pun, bagaimana kita bisa menggambarkan latensi secara bermakna? Jawabannya adalah kita harus melihat persentil dan maksimum. Kebanyakan orang berpikir dalam hati, oke, jadi saya melihat hasil P95 dan saya mengerti "kasus umum". Masalah dengan metode ini adalah bahwa P95 akan menyembunyikan semua hal buruk. Seperti yang dikatakan Gil Tene, CTO Azul Systems, “Ini adalah 'sistem pemasaran'. Seseorang sedang ditipu.”
Ambil, misalnya, grafik ini:
Ketika Anda melihat grafik ini, Anda dapat dengan jelas melihat mengapa median dan rata-ratanya tidak memiliki signifikansi yang nyata—mereka tidak menunjukkan area masalah. Ketika Anda melihat persentil ke-95 melonjak ke kiri, Anda mengira telah melihat inti masalahnya. Tentu saja, itu tidak benar. Ketika Anda menyelidiki mengapa program Anda mengalami gangguan kecil, Anda gagal melihat 5% terburuk dari apa yang terjadi. Untuk mendapatkan lonjakan semacam ini, 5% data teratas harus lebih buruk secara signifikan.
Sekarang lihat grafik yang sama yang juga menunjukkan persentil 99,99:
Garis merah itu adalah persentil ke-95, sedangkan garis hijau adalah persentil ke-99,99. Seperti yang dapat Anda lihat dengan jelas, persentil ke-95 hanya menunjukkan 2 dari 22 masalah Anda dan karena itulah Anda harus melihat spektrum penuh data.
Banyak orang mungkin mengira bahwa 5% data terakhir tidak memiliki banyak signifikansi. Tentu, itu bisa saja akibat mesin virtual (VM) yang baru dimulai kembali, gangguan kecil dalam sistem Anda atau yang seperti itu, tetapi dengan mengabaikannya Anda mengatakan bahwa itu tidak terjadi, padahal bisa menjadi salah satu hal terpenting yang harus Anda targetkan.
Gil Tene senang membuat klaim yang berani bahwa "Indikator nomor satu yang tidak boleh Anda singkirkan adalah nilai maksimum. Itu bukan ketidakakuratan, melainkan sinyal. Sisanya adalah ketidakakuratan.” Meskipun maksimum, memang, merupakan satu hal yang bagus dalam sistem pada skala besar, namun sering kali tidak praktis untuk hanya mengejar kasus maksimum. Tidak ada sistem yang sempurna, dan gangguan kecil memang terjadi. Dalam sistem praktis berskala besar, hanya mengejar kasus maksimum sering kali merupakan cara yang baik untuk melelahkan tim pengembangan Anda.
Ketika melihat persentil ke-99,99, Anda melihat apa yang terjadi pada sebagian besar pelanggan Anda, dan lonjakan apa pun yang Anda lihat di sana, Anda tahu bahwa itu adalah masalah yang sebenarnya, sedangkan lonjakan apa pun pada maksimum Anda mungkin hanya merupakan gangguan kecil dalam sistem Anda. Ketika tim DevOps Anda memfokuskan upaya mereka pada gangguan kecil ini, mereka melakukannya dengan biaya peluang yang besar, karena mereka tidak dapat bekerja pada masalah yang lebih besar sebagai gantinya.
Perlu dicatat bahwa jika persentil ke-99,99 dan maksimum Anda sangat dekat satu sama lain, dan keduanya melonjak, maka ini merupakan sinyal yang bagus bahwa ini adalah masalah yang harus ditangani oleh tim Anda. Dengan cara ini, Gil benar bahwa maksimum adalah sinyal yang bagus, tetapi salah bahwa sisa data Anda hanyalah ketidakakuratan. Seperti yang dapat Anda lihat dalam grafik ini, persentil 99,99 dan maksimum kami dari contoh sebelumnya sama persis. Ini adalah sinyal yang bagus bahwa apa yang Anda lihat adalah bug nyata dan bukan hanya gangguan kecil:
Jebakan yang lebih buruk lagi yang sering dilakukan orang selain melihat persentil ke-95 adalah gagal mengenali bahwa persentil mereka adalah rata-rata. Rata-rata persentil secara statistik tidak masuk akal; itu menghilangkan semua signifikansi dari apa yang Anda lihat. Kami telah menunjukkan bagaimana rata-rata tidak bagus ketika melihat latensi dan, jika Anda melihat persentil rata-rata, Anda akan kembali ke titik awal. Banyak program perangkat lunak merupakan rata-rata persentil Anda. Ambil, misalnya, bagan Grafana ini:
Apakah Anda menyadarinya sebelumnya atau tidak, semua persentil pada grafik ini rata-rata. Dikatakan demikian di buku besar sumbu x. Hampir semua layanan pemantauan adalah rata-rata persentil Anda. Ini adalah kenyataan akibat prakomputasi. Ketika layanan pemantauan Anda mengambil data Anda, persentil data untuk menit tersebut akan dihitung.
Kemudian ketika Anda melihat persentil ke-95 Anda, itu menunjukkan rata-rata dari semua persentil Anda. Jalan pintas untuk "kebaikan Anda" untuk membuat layanan Anda lebih cepat, pada kenyataannya, menghilangkan semua signifikansi statistik dari data Anda.
Entah Anda sadari atau tidak, dengan alat pemantauan yang berpartisipasi dalam pengambilan sampel data, mereka menghasilkan data rata-rata. Hampir setiap alat pemantauan mengambil sampel datanya. Ambil contoh, DataDog — ada kehilangan data yang besar. Jika Anda mengirim mereka 3 juta poin dalam satu menit, platform ini tidak akan mengambil semuanya. Sebaliknya, mereka akan mengambil sampel poin secara acak kemudian menggabungkannya menjadi 1 poin per menit.
Anda harus memiliki data tanpa sampel untuk memahami latensi Anda. Sudah melekat bahwa dengan data sampel Anda tidak dapat mengakses distribusi penuh. Maksimum Anda bukanlah maksimum Anda yang sebenarnya, dan persentil global Anda juga bukan merupakan representasi akurat dari apa yang sedang terjadi.
Saat Anda mengambil sampel data, Anda menghilangkan data. Katakanlah, misalnya, Anda memiliki 10.000 operasi yang terjadi dalam satu menit, masing-masing mengirimkan 2 titik data ke sistem pemantauan Anda. Katakanlah Anda memiliki bug di sistem Anda dan salah satu titik data ini menunjukkan bug ini per 10.000 operasi. Sistem pemantauan Anda hanya memiliki peluang 1/20.000 untuk memilih bug ini sebagai titik data yang ditunjukkan kepada Anda sebagai maksimum.
Jika Anda menjalankannya cukup lama, titik data akan muncul pada akhirnya, namun, hasilnya akan terlihat seperti kasus tepi yang sporadis, meskipun itu terjadi pada salah satu pelanggan Anda setiap menitnya. Ketika Anda tidak mengambil sampel data, dan Anda memiliki salah satu dari lonjakan ini, maka akan muncul dengan jelas di persentil ke-99,99, dan maksimum Anda akan muncul di dekatnya, yang menandakan bahwa Anda memiliki bug dalam program Anda. Namun, ketika Anda mengambil sampel data Anda, data tersebut tidak akan muncul sesering mungkin, yang berarti Anda tidak akan melihatnya sebagai bug, melainkan sebagai cegukan. Hasil ini berarti tim teknik Anda akan gagal menyadari pentingnya.
Jangan biarkan alat pemantauan Anda mengelabui Anda dan membuat Anda mengira tahu apa yang terjadi dengan latensi Anda. Salah satu fitur utama perangkat lunak IBM Instana adalah kemampuannya untuk mengukur latensi secara efisien. Perangkat lunak IBM Instana menggunakan analitik canggih dan machine learning (ML) untuk secara otomatis mendeteksi masalah latensi secara real-time, memungkinkan pengembang dan tim TI untuk dengan cepat mengidentifikasi akar masalah kinerja apa pun dan mengambil tindakan korektif sebelum berdampak pada pengguna.
Pilih alat yang tidak menyediakan data sampel. Pilih alat yang tidak rata-rata persentil global Anda.
IBM Cloud Pak for Network Automation adalah Cloud Pak yang memungkinkan otomatisasi dan orkestrasi operasi infrastruktur jaringan.
Solusi jaringan cloud dari IBM menyediakan konektivitas berkinerja tinggi untuk mendukung aplikasi dan bisnis Anda.
Konsolidasikan dukungan pusat data dengan IBM Technology Lifecycle Services untuk jaringan cloud dan banyak lagi.