Saat Peningkatan Kinerja yang Mengesankan Tidak Penting

• Optimalisasi kinerja adalah cara yang ampuh untuk memahami sistem kompleks dan meningkatkan produk, tetapi bahkan hasil 10x lebih cepat pun mungkin tidak mengubah cara kerja nyata atau throughput
• Bahkan jika respons kueri dipangkas dari 5~10 menit menjadi 30 detik~1 menit, efek yang dirasakan tetap terbatas bila masih melewati ambang sekitar 10 detik di mana manusia dapat terus menaruh perhatian sambil menunggu
• Jika pekerjaan terikat pada unit bilangan bulat seperti 1 atau 2 tugas per hari, peningkatan 25~50% saja tidak cukup; termasuk waktu perjalanan, setiap tugas harus menjadi 4 jam atau kurang agar 2 tugas per hari memungkinkan
• Dalam pipeline data, tahap yang lambat memberi backpressure ke hulu, sehingga walau satu tahap menjadi jauh lebih cepat, throughput end-to-end mungkin tidak naik sampai semua bottleneck teratasi
• Peningkatan kinerja harus dinilai berdasarkan hasil yang diinginkan, bukan benchmark per komponen; bila tidak mampu melewati batas seperti retensi perhatian, kenaikan unit kerja, atau throughput total, bahkan peningkatan besar pun berdampak kecil secara nyata

---

Mengapa angka kinerja dan hasil nyata bisa tidak selaras

• Pekerjaan kinerja itu memuaskan karena dapat membuat sistem lebih efisien dan membuka kemungkinan baru bagi pelanggan
• Ini juga membantu memahami secara empiris bagaimana sistem kompleks berinteraksi pada skala dan di bawah beban
• Saat menangani sistem dari dekat, sering muncul ide untuk memperbaiki produk dan layanan, dan sebagian darinya tidak berhubungan langsung dengan optimalisasi kinerja
• Namun, hasil yang terlihat bagus seperti “10x lebih cepat” atau “pengurangan resource 50%” tetap sulit menghasilkan perubahan yang diharapkan jika tidak melampaui batasan tersembunyi

Melewati 10 detik membuat perhatian pengguna terputus

• Ada kasus peningkatan performa kueri pada database baru, sehingga kueri termahal di database lama yang sebelumnya memakan 5~10 menit turun menjadi 30 detik~1 menit
• Hasil ini merupakan peningkatan sekitar 10x, tetapi untuk benar-benar mengubah pengalaman pengguna masih dibutuhkan satu lompatan besar lagi
• Dalam riset interaksi manusia-komputer, batas manusia untuk mempertahankan perhatian pada keseluruhan tugas dipandang sekitar 10 detik
  • 0,1 detik adalah ambang yang dirasakan sebagai umpan balik instan
  • Sekitar 1 detik adalah ambang agar alur kerja tetap terasa berlanjut
  • Sekitar 10 detik adalah ambang untuk mempertahankan perhatian pada keseluruhan tugas
  • Umpan balik seperti indikator progres atau estimasi waktu dapat membantu mempertahankan perhatian
• Karena 30 detik dan 5 menit sama-sama melewati 10 detik, pengguna akan memeriksa pesan, pergi mengambil kopi, memulai percakapan, atau beralih ke tugas lain
• Jika saat pengguna kembali beberapa menit atau beberapa jam kemudian UI sudah selesai dimuat, maka apakah waktu tunggu sebenarnya 30 detik atau 5 menit tidak banyak mengubah cara mereka bekerja
• Pada proyek tersebut, pada akhirnya banyak kueri berhasil ditekan menjadi 10 detik atau kurang, dan beberapa kueri yang sebelumnya mustahil karena timeout juga menjadi memungkinkan
  • Bukan hanya latensi kueri data, tetapi juga latensi kueri metadata dan waktu render halaman web yang penting untuk peningkatan performa secara keseluruhan
  • Dengan asynchronous IO dan perbaikan agregasi data, masih ada peluang peningkatan 10x lagi, dan itu dapat membuat kueri yang dulu memakan beberapa menit kembali dalam kurang dari 1 detik

Ambang dari 1 tugas per hari ke 2 tugas per hari

• Dalam satu proyek, otomatisasi pekerjaan manual, penghapusan langkah yang tidak perlu, sebagian paralelisasi, dan penundaan langkah yang bisa diproses asynchronous belakangan memangkas keseluruhan proses dari beberapa jam menjadi secara konsisten kurang dari 1 jam
• Besarnya peningkatan sekitar 25~50%, tetapi keseluruhan proses tidak berubah karena kendala logistik
• Ini bisa dibayangkan seperti tukang ledeng, teknisi listrik, atau tukang kayu yang harus menjadwalkan lokasi, bepergian ke sana, lalu menyelesaikan pekerjaan
  • Jika bekerja 8 jam sehari dan satu pekerjaan di satu lokasi memakan 8 jam, menghemat 2~3 jam tetap tidak cukup untuk pindah ke lokasi baru dan menyelesaikan pekerjaan baru
  • Termasuk waktu perjalanan, setiap pekerjaan harus menjadi 4 jam atau kurang agar 2 tugas per hari bisa diselesaikan
• Sebelum ambang seperti ini terlewati, peningkatan efisiensi pada tahap-tahap menengah tidak akan menghasilkan kenaikan output
• Fokus pada kinerja juga bisa sekaligus menghasilkan peningkatan kualitas dan keandalan yang langsung memengaruhi pengalaman pelanggan
  • Peningkatan performa kecil yang belum menjadi terobosan di produksi pun dapat mempercepat iterasi di lingkungan pengujian, sehingga pengembangan fitur dan penyelesaian bug menjadi lebih cepat

Bottleneck pada pipeline dengan backpressure

• Banyak infrastruktur perangkat lunak bisnis mencakup pipeline data yang memproses event dari berbagai sumber seperti kendaraan, peralatan pabrik, ponsel, atau transaksi keuangan
• Event biasanya disimpan ke log yang durable, lalu dikonsumsi dan diproses oleh layanan downstream
• Untuk skala besar dan throughput tinggi, log perlu dipartisi, dan layanan downstream menggunakan teknik seperti batching, pipelining, paralelisme, alokasi memori yang efisien, dan penskalaan dinamis
• Bottleneck dalam pipeline data sulit ditemukan karena perilaku sistem saling terkait
  • Tahap yang lambat dengan sengaja menerapkan backpressure ke tahap upstream
  • Jika ada beberapa bottleneck, throughput total tidak akan naik sampai bottleneck terakhir dihilangkan
• Membagi pipeline ke dalam beberapa tahap dan memahami karakteristik performa serta batas masing-masing tahap adalah praktik engineering yang baik
• Namun, bahkan jika satu tahap ditingkatkan beberapa orde besaran, throughput total bisa saja tidak terpengaruh
• Dalam peningkatan throughput, angka yang penting bukan benchmark tiap tahap, melainkan throughput end-to-end

Pendekatan empiris untuk menemukan bottleneck

• Untuk memahami dinamika dan bottleneck sistem seperti ini, pendekatan yang berguna adalah memeriksanya secara empiris mulai dari titik awal pipeline
• Misalnya mulai dari tahap membaca lalu membuang event dari distributed log
  • Jika tahap ini saja tidak dapat mencapai throughput target, maka mengoptimalkan tahap downstream hanya akan membuang waktu
• Benchmark downstream seperti berapa banyak baris per detik yang bisa dimasukkan ke database juga bisa penting, tetapi analisis harus dimulai dari upstream
• Simulasi juga merupakan cara yang bernilai untuk memahami sistem kompleks dan kinerja
  • Marc Brooker's Simple Simulations for System Builders
  • Try again: The tools and techniques behind resilient systems

Tolok ukur peningkatan kinerja adalah hasil yang diinginkan

• Pekerjaan kinerja itu sulit, tetapi juga merupakan latihan untuk memahami sistem kompleks secara mendalam dan membangun produk yang lebih baik
• Jika ingin mempertahankan perhatian manusia, respons harus datang dalam sekitar 10 detik
• Jika kendalanya adalah unit kerja secara keseluruhan, peningkatan berbasis persentase saja tidak cukup; hasilnya harus mampu membawa dari 1 tugas per hari ke 2 tugas per hari
• Untuk memaksimalkan throughput pipeline yang memiliki backpressure, sering kali yang perlu diselesaikan bukan satu atau dua bottleneck, melainkan semua bottleneck
• Jika batasan-batasan ini tidak terlewati, bahkan peningkatan kinerja setingkat 10x pun tidak akan menghasilkan hasil yang diinginkan

[GN⁺]

Komentar di Lobste.rs

• Jika kasusnya adalah memperbaiki satu tahap puluhan kali lipat lalu kecewa karena tidak berdampak pada throughput keseluruhan, di sini layak menyinggung hukum Amdahl

  • Saya penasaran apakah ada semacam kumpulan nama-nama hukum di seluruh ilmu komputer
    Saya terus mendengar hukum baru, tetapi karena cukup niche sehingga tidak sering dipakai, saya akhirnya melupakannya lagi. Bukan berarti hukum-hukum itu tidak valid atau tidak berguna sebagai pengetahuan lintas generasi

• Saya bertanya-tanya kenapa sejak awal mereka mengoptimalkan bagian yang hanya mengambil porsi sangat kecil dari total waktu
  Entah panduannya yang buruk, atau tooling performanya kurang. Jarang ada orang yang secara sadar mau mengerjakan sesuatu yang nyaris tidak berdampak; biasanya ada masalah yang lebih besar tersembunyi

  • Menurut saya salah satu jalur terjadinya hal seperti ini kira-kira begini
    Saat melihat suatu masalah, hasil sampling menunjukkan fungsi tertentu terlihat besar, dan setelah dilihat sebentar implementasinya tampak cukup mudah diperbaiki. Namun karena sedang mengerjakan hal lain, itu ditunda dengan pikiran “nanti dikerjakan”
    Belakangan, perbaikan yang mudah itu teringat lalu mulai dikerjakan, tetapi ketika ternyata perubahannya lebih rumit dari dugaan, muncul tunnel vision dan keinginan memecahkan teka-tekinya, sehingga banyak waktu terpakai
    Padahal sebenarnya masalah performa itu sepele. Dalam konteks yang dilihat saat itu ia tampak besar secara proporsi, atau waktu absolutnya tidak terlalu berarti, atau situasinya terhambat I/O, bukan CPU. Ini mirip semacam nerd sniping yang dilakukan pada diri sendiri
  • Di Google, pernah ada usulan untuk mengoptimalkan sebagian pipeline, dan beberapa orang menjelaskan bahwa bagian itu kurang dari 0,1% dari total komputasi, jadi keuntungan keseluruhannya juga menurut definisi kurang dari 0,1%
    Namun itu tetap diabaikan dan optimisasi dilanjutkan; ketika peningkatan keseluruhannya ternyata kurang dari 0,1%, mereka bingung. Dengan pengetahuan domain, bagian itu secara intuitif pun bukan bagian yang mahal, tetapi kami bahkan membantu mengukur biaya performa sebenarnya agar waktu tidak terbuang
  • Bisa jadi mereka bergerak berdasarkan tebakan, sudah menginternalisasi praktik terbaik yang selalu diterapkan, atau terlalu menggeneralisasi masalah nyata yang mereka lihat dalam situasi terbatas
    Atau benchmark-nya mungkin menyesatkan. Tidak semua sistem mudah memperlihatkan biaya setiap metode atau proses di lingkungan produksi
    Penjelasan-penjelasan ini, dengan derajat yang berbeda-beda, semuanya mendekati disfungsi; sebagian lebih merupakan masalah individu, sebagian lebih merupakan masalah lingkungan
  • Ada beberapa alasan yang mungkin
    1. Engineer junior berbakat telah belajar memecahkan masalah, tetapi belum belajar memilih masalah yang layak dipecahkan. Ia menyerang setiap inefisiensi yang ditemukan tanpa memedulikan dampak end-to-end. Kalau beruntung, seseorang akan mengajarinya; kalau tidak, ia mandek menjadi engineer senior yang harus dikendalikan ketat oleh PM
    2. Performa end-to-end tidak bisa dilihat dengan benar. Ada penurunan performa di suatu tempat dalam sistem dan manajemen memberi tekanan, tetapi tidak ada wewenang untuk memasang monitoring yang layak, jadi mereka menyentuh berbagai komponen berdasarkan tebakan dan berharap salah satunya tepat. Setelah kebakaran padam, mereka kembali merilis fitur pengguna
    3. Saat ini bukan masalah, tetapi diperbaiki lebih dulu karena dikhawatirkan akan segera menjadi masalah. Jika pengaruhnya cukup atau bisa memaksa lembur, pekerjaan tetap berjalan meski tidak ada efek yang langsung terlihat. Engineer hebat pun akan memakai modal politik untuk hal seperti ini jika mereka percaya itu penting di masa depan, sementara engineer yang kurang baik akan menghabiskan semuanya
       3.1. Jika bekerja di hyperscaler, penghematan komputasi 0,1% yang sama sekali tidak terlihat oleh pengguna pun bisa berdampak pada laba-rugi sebesar harga rumah di tepi pantai
    4. Tidak tahan terhadap tantangan. Mereka tahu sebenarnya tidak akan ada yang berubah, tetapi bosan hanya membuat aplikasi CRUD, lalu ada kesempatan mencoba sesuatu yang mereka lihat di blog. Dengan kata lain, mereka melakukan nerd snipe pada diri sendiri untuk mengurangi beratnya rasa tidak bermakna
  • Berlawanan dengan anggapan umum, banyak sistem tidak hanya terdiri dari beberapa bottleneck
    Praktik pemrograman umum itu sendiri sering kali lambat secara menyeluruh. Misalnya kode berorientasi objek dengan banyak pointer dan alokasi heap yang sangat banyak lewat allocator umum. Di bagian mana pun diperbaiki, itu hanya potongan kecil dari total waktu, sehingga dalam kasus terburuk tidak ada solusi selain menulis ulang total. Jika beruntung, bisa ditulis ulang secara bertahap
    Bahkan jika bottleneck-nya hanya dua, kalau keduanya berada dalam rentang faktor satu digit satu sama lain, memperbaiki bottleneck terburuk secara sempurna pun tidak akan menghasilkan peningkatan sampai faktor satu digit. Dalam banyak kasus, seperti yang dikatakan tulisan itu, untuk mendapat keuntungan bermakna perlu melampaui itu jauh lebih besar
    Selain itu, komputer lebih mirip sistem terdistribusi yang berjalan paralel. Ada beberapa CPU, GPU, disk, Ethernet, dan sebagainya, dan kecepatan proses dibatasi oleh tahap paling lambat dalam pipeline. Setelah tahap itu diperbaiki, tahap paling lambat berikutnya menjadi pembatas, dan dalam kasus terburuk ada beberapa tahap paling lambat sehingga memperbaiki satu saja tidak memberi keuntungan apa pun
    Namun ini penjelasan yang berprasangka baik; kadang orang memang sekadar terjebak dalam permainan optimisasi lalu kehilangan prioritas atau membuat kesalahan

• Walaupun pengguna tidak menyadarinya, pengurangan waktu komputasi perangkat lunak tetap baik
  Karena bisa menurunkan biaya dan membuat scaling lebih mudah

  • Itu tergantung pada biaya kompleksitasnya
    Jika membuat kode lebih cepat membawa kompleksitas berlebihan, maka bahkan terlepas dari maintainability, ada konsekuensi lanjutan yang merusak performa dalam jangka panjang. Saat struktur berubah, kode yang kini menjadi tidak perlu tetap tertinggal, dan untuk memahami atau menghapusnya orang harus sepenuhnya memahami seluruh kompleksitasnya
    Alasan “jadi lebih cepat” tidak boleh menjadi surat pembebasan untuk mengabaikan kekhawatiran soal kompleksitas atau maintainability

• Saya sedang berada dalam situasi serupa, dan lewat beberapa proyek kecil sedang menurunkan query yang dulu butuh 5 menit menjadi di bawah 30 detik
  Saya mengatakan kepada tim bahwa ini belum cukup untuk jangka panjang, tetapi jelas merupakan perbaikan dan dampaknya besar
  Dari sisi pelanggan, menunggu turun dari tingkat yang membuat marah besar menjadi sekadar menyebalkan
  Fokus saat ini bukan performa per pengguna, melainkan performa keseluruhan. Jika puluhan proses berdurasi 5 menit, 10 menit, 30 menit dioptimalkan, kontensi dengan bagian lain sistem akan jauh berkurang. Menghantam database selama 10 menit adalah waktu yang sangat lama, dan pada akhirnya semuanya menjadi lebih cepat sehingga semua orang diuntungkan