Aplikasi Mulai Lambat? Jangan Langsung Salahin Server

Aplikasi Mulai Lambat Jangan Langsung Salahin Server - Sagara Xinix IT Solution POWERHOUSE

Ada satu kalimat yang paling sering muncul waktu aplikasi mulai terasa berat, semakin terasa ketika aplikasi mulai lambat:

“Kayaknya servernya kurang kuat, upgrade aja deh.”

Kedengarannya masuk akal. Tapi di banyak kasus, menambah server itu seperti minum obat penurun panas waktu yang sakit sebenarnya gigi. Demamnya turun sebentar, masalahnya tetap ada.

Artikel ini buat kamu yang masih baru di dunia IT. Kita bahas dua hal saja:

  • penyebab yang sebenarnya bikin aplikasi lambat, dan
  • cara menemukannya tanpa tebak-tebakan.

Apa Itu Bottleneck?

Bottleneck secara harfiah berarti “leher botol”. Bayangkan kamu menuang air dari botol. Seberapa besar pun badan botolnya, kecepatan air keluar ditentukan oleh bagian lehernya yang sempit. Aplikasi bekerja dengan cara yang sama. Satu request dari user melewati banyak bagian sistem. Kalau ada satu bagian yang lambat, seluruh request ikut lambat, walaupun bagian lain sudah cepat. Jadi pertanyaannya bukan “aplikasi saya lambat, gimana biar cepat?” Pertanyaan yang benar adalah: “di bagian mana aplikasi saya melambat?” Untuk menjawabnya, kita perlu tahu bahwa aplikasi terdiri dari beberapa lapisan (layer). Ada empat layer yang paling sering jadi biang keroknya.

Layer 1: Database

Masalah yang sering terjadi pada Layer Database

Database adalah tempat data disimpan. Setiap kali aplikasi butuh data, ia mengirim perintah yang disebut query. Dua masalah paling umum di sini:

1. Query tanpa index

Index itu seperti daftar isi di buku. Kalau kamu cari kata “fotosintesis” di buku 500 halaman tanpa daftar isi, kamu harus buka satu per satu dari halaman pertama. Database melakukan hal yang persis sama. Tanpa index, ia memeriksa seluruh baris di tabel, satu per satu. Dengan 100 baris data, ini tidak terasa. Dengan 5 juta baris, ini terasa sekali.

2. Pola N+1 query

Ini masalah klasik yang sering tidak disadari pemula. Misalnya, Kamu mau menampilkan 100 artikel beserta nama penulisnya. Kode kamu:

  • 1 query untuk mengambil 100 artikel
  • lalu di dalam loop, 1 query lagi untuk mengambil nama penulis tiap artikel

Total: 101 query untuk satu halaman. Padahal seharusnya cukup 1 atau 2 query saja. Di local dengan 10 data, tidak kerasa. Di production dengan ribuan data, halaman jadi berat.

Cara Mengeceknya

  1. Nyalakan query log atau slow query log. Hampir semua database punya fitur untuk mencatat query yang jalannya di atas batas waktu tertentu, misalnya lebih dari 1 detik. Dari situ kamu langsung tahu query mana yang jadi tersangka.
  2. Pakai EXPLAIN di depan query kamu. Perintah ini memperlihatkan bagaimana database mengeksekusi query. Kalau hasilnya menunjukkan “full table scan” atau “sequential scan”, artinya index tidak terpakai.
  3. Hitung jumlah query per halaman. Kalau kamu pakai framework (Laravel, Rails, Django, dan sejenisnya), biasanya ada debug toolbar yang menampilkan jumlah query per request. Kalau satu halaman menghasilkan 80 query, itu tanda kuat N+1.

Layer 2: Application Code

Masalah yang sering terjad pada Layer Applicaiton Code

Ini adalah logic yang kamu tulis sendiri. Dua penyebab lambat yang paling sering:

1. Logic yang tidak efisien

Misalnya melakukan perhitungan berat berulang-ulang untuk hasil yang sama, atau memproses data di memory padahal bisa diserahkan ke database.

2. Proses berat yang dijalankan secara synchronous

Ini yang paling sering terjadi dan paling mudah diperbaiki. Synchronous artinya “dikerjakan berurutan, yang berikutnya menunggu yang sebelumnya selesai”. Contoh nyata: user klik tombol Daftar, lalu kode kamu mengirim email verifikasi langsung di dalam request itu juga. Kirim email butuh 3 detik? Berarti user menatap loading selama 3 detik, padahal akunnya sudah jadi sejak detik pertama. Solusinya adalah memindahkan pekerjaan itu ke background job atau queue. Konsepnya sederhana: aplikasi menyimpan tugas ke antrean, langsung menjawab user “berhasil”, lalu ada worker terpisah yang mengerjakan antrean itu di belakang layar. Analoginya seperti restoran. Pelayan tidak berdiri diam menunggu masakanmu matang sebelum melayani meja lain. Dia mencatat pesanan, oper ke dapur, lalu lanjut kerja.

Cara Mengeceknya

  1. Pakai profiler atau APM (Application Performance Monitoring). Tool seperti ini memecah satu request jadi potongan waktu: berapa lama di database, berapa lama di kode kamu, berapa lama menunggu API luar.
  2. Kalau belum punya tool, mulai dari logging manual. Catat timestamp di beberapa titik dalam fungsi yang kamu curigai, lalu lihat jeda terbesar ada di mana.
  3. Cari kata kunci mencurigakan di dalam controller atau route handler: pengiriman email, generate PDF, upload ke storage, panggilan ke API luar, atau looping panjang. Kalau ada di jalur request, itu kandidat kuat untuk dipindah ke queue.

Layer 3: Network dan API

Masalah yang sering terjad pada Layer Network dan API

Aplikasi modern jarang berdiri sendiri. Ia bicara dengan payment gateway, layanan pengiriman pesan, peta, penyimpanan file, dan lainnya. Di sini masalahnya:

1. Payload API terlalu besar

Payload adalah data yang dikirim bolak-balik. Kalau endpoint kamu mengembalikan 5.000 baris data lengkap dengan semua kolom padahal user cuma lihat 20 baris pertama, kamu membuang waktu untuk mengirim data yang tidak dipakai.

2. Bergantung pada layanan pihak ketiga yang lambat

Kalau aplikasi kamu memanggil API luar dan API itu butuh 4 detik untuk menjawab, aplikasi kamu ikut lambat 4 detik. Padahal kode kamu tidak salah apa-apa.

Cara Mengeceknya

  1. Buka Network tab di browser (klik kanan, Inspect, lalu tab Network). Reload halaman, lalu urutkan berdasarkan waktu. Kamu akan langsung lihat request mana yang paling lama dan seberapa besar ukurannya.
  2. Cek ukuran response. Kalau satu endpoint mengembalikan beberapa MB, pertimbangkan pagination (pecah jadi beberapa halaman) atau kirim hanya kolom yang benar-benar dipakai.
  3. Ukur waktu respons API pihak ketiga secara terpisah, misalnya dengan curl atau Postman. Kalau di luar aplikasi pun sudah lambat, masalahnya bukan di kamu. Yang bisa kamu lakukan adalah menambahkan timeout, caching, atau memindahkannya ke background job.

Layer 4: Infrastruktur

Masalah yang sering terjadi pada Layer Infrastruktur

Ini layer yang paling sering disalahkan duluan, padahal seharusnya dicek paling akhir. Infrastruktur berarti sumber daya fisik atau virtual tempat aplikasi berjalan: CPU, RAM, disk, dan bandwidth. Kalau resource-nya memang sudah tidak cukup untuk beban saat ini, aplikasi akan lambat sekalipun kodenya rapi. Kuncinya ada di kata “memang sudah tidak cukup”. Kalau CPU kamu jalan di 15 persen tapi aplikasi tetap lambat, menambah CPU tidak akan mengubah apa pun.

Cara Mengeceknya

  1. Lihat penggunaan resource saat aplikasi sedang lambat, bukan saat sepi. Di Linux kamu bisa pakai perintah dasar seperti top, htop, atau free -h untuk melihat CPU dan RAM.
  2. Perhatikan polanya. CPU mentok 100 persen terus menerus berarti beda cerita dengan CPU yang cuma naik sesaat. Yang pertama masalah kapasitas, yang kedua biasanya masalah kode.
  3. Cek disk dan memory juga, bukan cuma CPU. Server yang kehabisan RAM akan mulai memakai swap, dan itu membuat semuanya melambat drastis.

Alur Diagnosis yang Benar

Empat layer di atas saling terhubung, tapi cara mendiagnosisnya berbeda. Ini urutan yang bisa kamu pakai:

Langkah 1Reproduksi dan ukur.
Pastikan dulu lambatnya di mana. Halaman tertentu saja, atau semua halaman? Jam tertentu saja, atau sepanjang hari? Catat angkanya, misalnya “halaman dashboard butuh 8 detik”.
Langkah 2 Pecah waktunya.
Dari 8 detik itu, berapa detik di database, berapa di kode, berapa menunggu API luar? Di sinilah profiling atau monitoring berperan. Tanpa angka, kamu cuma menebak.
Langkah 3 Serang bagian terbesar dulu.
Kalau 6 dari 8 detik ternyata habis di database, memperbaiki kode yang cuma makan 0,3 detik tidak akan terasa dampaknya. Selalu perbaiki yang porsinya paling besar.
Langkah 4 Ukur ulang.
Setelah perbaikan, ukur lagi dengan cara yang sama. Kalau tidak membaik, berarti asumsinya salah dan kamu perlu kembali ke langkah 2.
Langkah 5 Baru bicara soal infrastruktur.
Kalau kode sudah efisien, query sudah pakai index, proses berat sudah masuk queue, dan resource memang benar-benar mentok, barulah menambah kapasitas jadi keputusan yang tepat.

Kenapa “Tambah Server” Bukan Selalu Jawabannya

Menambah server itu menarik karena cepat dan tidak butuh mengubah kode. Tapi ada tiga konsekuensinya:

  1. Biayanya permanen. Query yang salah cuma perlu diperbaiki sekali. Server tambahan ditagih setiap bulan, selamanya.
  2. Masalahnya cuma tertunda. Kalau penyebabnya N+1 query, pertumbuhan data akan membuat masalah yang sama muncul lagi dalam beberapa bulan.
  3. Sebagian masalah tidak peduli ukuran server. Kalau API pihak ketiga butuh 4 detik untuk menjawab, server sebesar apa pun tetap menunggu 4 detik.

Checklist Praktis Buat Pemula

Simpan daftar ini. Saat aplikasi terasa lambat, jalankan dari atas:

  • [ ✅ ] Buka Network tab, cari request paling lambat
  • [ ✅ ] Cek jumlah query per halaman, waspadai angka yang tidak wajar
  • [ ✅ ] Jalankan EXPLAIN pada query yang paling berat
  • [ ✅ ] Cari proses berat yang jalan synchronous di dalam request
  • [ ✅ ] Ukur waktu respons API pihak ketiga secara terpisah
  • [ ✅ ] Lihat CPU dan RAM saat kondisi sedang lambat
  • [ ✅ ] Perbaiki bagian dengan porsi waktu terbesar
  • [ ✅ ] Ukur ulang untuk memastikan perbaikannya berhasil

Penutup

Performa itu bukan soal menebak dengan benar. Ini soal mengukur dengan benar. Pemula sering mengira engineer senior lebih jago menebak. Kenyataannya tidak. Mereka cuma lebih disiplin mengumpulkan data sebelum menyentuh apa pun. Monitoring dan profiling bukan tool untuk orang expert saja, justru itu yang membuat seseorang jadi expert.

Di Sagara Xinix, kami percaya Technology should follow the problem. Bukan sebaliknya.

Punya masalah IT? email hello@sagara.id. Sagara Xinix | IT Solution POWERHOUSE