Malang, http://gajayanatvnews.com – Dalam pengembangan aplikasi backend, kecepatan dan ketangguhan server dalam menangani permintaan secara bersamaan adalah salah satu indikator penting. Pertanyaan sederhananya, seberapa banyak pengguna bisa mengakses endpoint secara paralel tanpa membuat server kelelahan? Untuk menjawabnya, saya membuat sebuah simulasi sederhana menggunakan bahasa Go, memanfaatkan kekuatan concurrency-nya yang terkenal efisien.
Tujuan dari eksperimen ini adalah untuk memahami bagaimana goroutine dan channel di Go dapat bekerja secara bersamaan dalam satu endpoint, lalu menguji performanya menggunakan alat stress test bernama hey. Eksperimen ini tidak hanya berfokus pada hasil angka, tetapi juga pada proses membangun simulasi kerja paralel dengan cara yang sederhana namun representatif terhadap kebutuhan backend modern.
Golang memiliki pendekatan concurrency yang khas dan elegan melalui konsep goroutine dan channel. Goroutine memungkinkan kita menjalankan fungsi secara paralel dengan sangat ringan, sedangkan channel berperan sebagai media komunikasi di antara goroutine. Dengan dua konsep ini, kita bisa membangun sistem kerja paralel yang tidak rumit namun efektif mirip seperti membentuk tim kecil yang saling menyelesaikan tugas lewat jalur komunikasi internal.
Sebelum masuk ke eksperimen utamanya, saya memulai dengan menyiapkan lingkungan pengembangan terlebih dahulu. Bahasa Go bisa diunduh secara gratis melalui situs resminya di go.dev, dan proses instalasinya cukup sederhana untuk sistem operasi Windows. Setelah terpasang, saya membuat direktori proyek baru lalu menginisialisasi modul dengan perintah go mod init. Ini menjadi fondasi agar proyek lebih terstruktur dan mudah dijalankan ulang di mesin manapun.
Menariknya, meskipun server saya jalankan dari PowerShell di Windows, proses pengujian beban saya lakukan dari WSL (Windows Subsystem for Linux). Ini memungkinkan saya untuk menjalankan tool hey langsung dari Linux environment, seolah-olah datang dari klien luar. Untuk menginstal hey, saya cukup menjalankan perintah go install github.com/rakyll/hey di WSL, lalu memastikan binary-nya bisa diakses lewat terminal. Setup ini memang sedikit hybrid, tapi justru menunjukkan fleksibilitas ketika bekerja lintas sistem dalam praktik backend modern.
Karena localhost di WSL tidak bisa langsung mengakses server yang berjalan di Windows, saya menggunakan IP virtual yang menghubungkan keduanya, yaitu 172.30.0.1. Dengan IP ini, saya bisa menjalankan hey -n 500 -c 20 http://172.30.0.1:8080/process untuk mengirim 500 permintaan paralel dengan 20 koneksi sekaligus. Semua langkah teknis serta struktur kodenya sudah saya dokumentasikan dalam repositori GitHub berikut: https://github.com/samudsamudra/golang-concurrency-hey. Kita bisa melihat langsung bagaimana simulasi concurrency dijalankan dan hasil stress test-nya dianalisis.
Setelah server berjalan dan pengujian dilakukan, hey menghasilkan rangkuman statistik performa yang cukup informatif. Dalam simulasi ini, seluruh 500 permintaan berhasil dijalankan tanpa ada satu pun error, dengan rata-rata waktu respons sekitar 91 milidetik per permintaan. Angka ini menunjukkan bahwa server dapat menangani beban paralel secara konsisten tanpa mengalami bottleneck atau keterlambatan ekstrem. Bahkan pada permintaan paling lambat sekalipun, respons tidak pernah melebihi 104 milidetik sebuah angka yang tergolong responsif dalam skenario lokal.
Salah satu metrik yang cukup mencolok adalah nilai Requests per Second (RPS) yang mencapai 211 permintaan per detik. Artinya, meskipun server hanya menangani simulasi sederhana, struktur concurrency di dalamnya sudah mampu memproses lebih dari dua ratus permintaan setiap detiknya secara stabil. Ini adalah indikasi awal yang baik, khususnya jika kita membayangkan skenario serupa diterapkan pada aplikasi nyata yang membutuhkan proses batch paralel, seperti memvalidasi data masif, menjalankan pipeline analitik, atau menangani request API internal antar layanan.
Metrik lain seperti distribusi latensi dan histogram respons juga mengonfirmasi stabilitas performa. Hampir seluruh permintaan selesai dalam rentang waktu 80–100 milidetik, dengan distribusi yang merata dan tidak menunjukkan lonjakan tiba-tiba. Ini berarti tidak ada permintaan yang “tertinggal jauh” atau menyebabkan antrian mendadak, sesuatu yang sering terjadi jika sistem tidak mampu menyeimbangkan beban. Dengan kata lain, sistem sederhana ini menunjukkan bahwa concurrency di Go memang bukan sekadar jargon teknikal, tapi benar-benar menawarkan fondasi praktis yang kuat untuk membangun aplikasi yang efisien.
Tentu, eksperimen ini masih jauh dari kompleksitas dunia nyata.
Tidak ada interaksi dengan database, tidak ada middleware, dan tidak ada komponen tambahan seperti caching, autentikasi, atau logika bisnis yang rumit. Namun justru karena kesederhanaannya, eksperimen ini memberikan gambaran dasar yang bersih dan jelas tentang bagaimana concurrency bekerja di level paling fundamental.
Dari situ, pengembang bisa mulai membangun sistem yang lebih kompleks dengan pemahaman yang lebih kuat mengenai bagaimana server mereka akan berperilaku di bawah tekanan.
Selain itu, pendekatan seperti ini juga bisa menjadi langkah awal untuk mengenalkan prinsip observability dan monitoring dalam proyek backend. Setelah melihat bagaimana sistem merespons permintaan paralel dalam kondisi ideal, langkah berikutnya adalah mengintegrasikan metrik real-time, logging, dan alerting untuk memastikan sistem tetap sehat saat dihadapkan pada trafik nyata yang tidak selalu stabil. Hal ini akan sangat membantu ketika aplikasi mulai memasuki tahap produksi atau ketika digunakan oleh banyak pengguna secara bersamaan.
Sebagai penutup, eksperimen ini menunjukkan bahwa concurrency di Go bukan hanya mudah diimplementasikan, tapi juga dapat langsung diuji efektivitasnya melalui alat yang sederhana. Dengan pengaturan lingkungan yang tepat dan sedikit eksplorasi terhadap alat seperti hey, kita bisa mendapatkan wawasan teknis yang berguna untuk menilai ketahanan sistem kita sendiri. Dan lebih dari itu, eksperimen semacam ini bisa jadi latihan yang menyenangkan di mana belajar performa server tidak harus selalu diawali dengan kompleksitas, tapi cukup dengan pertanyaan sederhana: sanggupkah server kita melayani 500 orang yang datang barengan?
(Yohanes Capelliou Samudra)
