Panduan Optimasi Kinerja Aplikasi Go

Panduan Optimasi Kinerja Aplikasi Go

• Kumpulan referensi teknis untuk mengembangkan aplikasi Go berkinerja tinggi
• Menyediakan pola praktis, studi kasus, dan wawasan kinerja tingkat rendah bagi engineer yang mengembangkan API, microservice, dan sistem terdistribusi berkinerja tinggi
• Go memang tidak menawarkan banyak opsi tuning performa seperti C++ atau Rust, tetapi tetap menyediakan banyak peluang optimasi seperti penggunaan ulang memori, kontrol alokasi, serta penanganan jaringan dan konkurensi yang efisien
• Panduan ini berfokus pada teknik peningkatan performa yang terukur, mulai dari fitur inti bahasa hingga strategi jaringan tingkat lanjut

Topik yang sudah dibahas sejauh ini

Pola kinerja Go yang umum

• Artikel pertama yang merangkum pola kinerja inti yang perlu diketahui semua pengembang Go
• Topik utama:
  • Penggunaan sync.Pool yang efektif
  • Menghindari alokasi memori yang tidak perlu
  • Optimasi layout struct dan alignment memori
  • Penanganan error yang efisien
  • Abstraksi tanpa biaya melalui interface
  • Teknik penggunaan ulang slice dan pengurutan in-place
• Ditulis berdasarkan contoh nyata di lapangan, termasuk benchmark dan contoh kode yang bisa langsung disalin

Topik yang akan dibahas selanjutnya

Jaringan berkinerja tinggi di Go

• Akan ada analisis mendalam tentang pembangunan layanan jaringan berkinerja tinggi dengan memanfaatkan standard library dan library eksternal
• Topik yang akan dibahas:
  • Penggunaan net/http dan net.Conn secara efisien
  • Penanganan koneksi konkuren dalam skala besar
  • Tuning performa dengan memanfaatkan epoll/kqueue, GOMAXPROCS, dan lain-lain
  • Teknik load testing dan diagnosis bottleneck
  • Kapan sebaiknya menggunakan library jaringan tingkat rendah seperti fasthttp dan bagaimana menyeimbangkannya dengan maintainability

Pembaca yang dituju

• Backend engineer yang mengoptimalkan layanan Go di production
• Pengembang yang menangani sistem sensitif terhadap latensi
• Tim yang sedang bermigrasi ke Go atau membangun jalur berkinerja tinggi
• Pengembang yang tertarik pada model performa Go dan trade-off-nya

[GN⁺]

Komentar Hacker News

• Saat melihat contoh pertama tentang object pool, saya terkejut karena ternyata itu dimungkinkan tanpa peringatan

  • API ini sudah ada sebelum generics, jadi menggunakan any
  • Secara prinsip Golang memiliki sistem tipe yang kuat, tetapi dalam praktiknya ada banyak API yang keluar dari sistem tipe
  • Jadi muncul pertanyaan apakah sistem tipe benar-benar berguna
  • Fakta bahwa tidak ada API untuk mereset nilai ke nilai default yang telah diinisialisasi juga patut diperhatikan

• Panduan performa merekomendasikan meminimalkan alokasi untuk mengurangi waktu GC

  • Fase mark pada GC memakan waktu, dan sebaiknya menghindari alokasi yang berumur panjang
  • Alokasi yang berumur pendek hampir tidak memengaruhi waktu GC
  • Dalam aplikasi nyata, hampir mustahil menghindari GC, dan lebih efektif mengurangi waktu mark GC

• Selain itu...

  • Panduan optimisasi Go
  • Panduan Uber Go
  • Sulit mengingat hal-hal penting saat berpindah-pindah proyek lintas bahasa selama 6 bulan

• Zero-copy diremehkan

  • Interface di Go cocok untuk menulis kode zero-copy, tetapi perlu kehati-hatian
  • Sering kali baru sadar bahwa banyak waktu habis untuk alokasi dan pemindahan memori

• GOMEMLIMIT sudah beberapa kali membantu

  • Berguna di production yang dikontainerisasi, dan menyelesaikan masalah kehabisan memori di CI
  • Beralih ke nogo juga menyelesaikan masalah golangci-lint

• Penasaran dengan proyek yang memang membutuhkan optimisasi

  • Misalnya: penyelarasan field struct

• Saat melihat dokumentasi object pooling, jadi penasaran apakah ada rencana membuat package seperti sync menjadi generic

• Terkejut bahwa Golang mirip dengan C dalam hal penyelarasan struct

• "Struct Data berisi array [1024]int, yang berukuran 4KB"

  • Jadi bertanya-tanya apakah masih ada orang yang memakai arsitektur 32-bit sebagai default

• Anda bisa menipu diri sendiri dengan memakai sync.Pool

  • pprof terlihat bagus karena tidak ada alokasi dalam benchmark, tetapi penggunaan memori nyata justru meningkat
  • Penting untuk mengukur manfaatnya di dunia nyata