Website paling sering down justru saat paling dibutuhkan: ketika sedang viral, ketika ada promo, atau ketika calon pelanggan sedang siap membeli. Momen yang seharusnya jadi panen malah berubah jadi panik.
Kenapa Ini Sering Terjadi
Banyak layanan hosting murah menjalankan ratusan, kadang ribuan website di satu server yang sama, tanpa batas sumber daya yang tegas antar website. Selama semuanya sepi, tidak ada masalah. Begitu satu website mengalami lonjakan traffic atau serangan, website lain di server yang sama bisa ikut terdampak. Penyebabnya bukan websitemu, melainkan tetangga yang berebut sumber daya yang sama.
Ini juga bukan semata soal harga. Harga mahal tidak otomatis berarti arsitekturnya lebih siap. Kalau desainnya sama-sama berbagi sumber daya tanpa isolasi per website, berapa pun tagihannya, hasilnya bisa tetap lambat atau down saat traffic naik tiba-tiba. Yang membedakan adalah apakah sistemnya dirancang untuk kondisi ramai sejak awal, atau baru ditambal setelah kejadian.
Cara Kami Menguji
Kami tidak mau sekadar mengatakan sistem kami aman tanpa bukti. Salah satu tahap produksi di JadiWeb adalah stress test: kami mensimulasikan banyak pengunjung sekaligus untuk melihat di titik mana sistem mulai goyah, sebelum itu terjadi di depan calon pelanggan klien kami.
Pengujian terakhir memakai k6 dengan 100 pengunjung virtual bersamaan selama 5,5 menit. Ini beban yang stabil dan terus-menerus, bukan lonjakan sesaat. Hasilnya: 7.688 request diproses, semuanya berhasil dan tidak ada yang gagal. Waktu respons rata-rata 13,69ms, 95% request selesai di bawah 17,37ms, dan 99% request selesai di bawah 20,1ms.
Jeda Saat Worker Sedang Tidur
Ada satu hal yang perlu kami akui. Sistem kami tidak menyalakan semua website sepanjang waktu. Tiap website berjalan di unit pemroses terpisah (worker) yang otomatis dimatikan saat tidak ada yang mengakses, supaya sumber daya server tidak terbuang untuk website yang sedang sepi. Konsekuensinya, pengunjung pertama setelah worker tidur akan menunggu sebentar sampai worker menyala lagi.
Dari pengukuran kami, jeda itu awalnya sekitar 1 sampai 1,6 detik. Setelah dioptimasi, waktu startup turun sampai sekitar 650ms. Angka itu kemungkinan sudah mendekati batas proses startup itu sendiri, sehingga sulit ditekan lebih jauh lewat perbaikan kode saja.
Namun 650ms tetap terasa kalau dialami setiap pengunjung. Karena itu kami memasang Varnish sebagai lapisan cache di depan sistem. Halaman yang sudah ada di cache dilayani langsung tanpa membangunkan worker. Worker hanya dibangunkan saat ada permintaan yang belum tersimpan di cache, dan pengunjung berikutnya untuk halaman yang sama tidak lagi merasakan jeda itu.
Batas dari Pengujian Ini
Hasil di atas perlu dibaca bersama batasnya. Pengujian ini mengukur ketahanan terhadap traffic yang stabil dan berkelanjutan dari 100 pengguna bersamaan. Ia tidak menguji lonjakan mendadak yang jauh lebih besar, tidak menguji serangan seperti DDoS, dan tidak mengukur uptime dalam jangka panjang. Hasilnya berasal dari satu sesi pengujian yang kami jalankan sendiri, bukan audit pihak ketiga. Jadi angka ini menunjukkan sistem bertahan pada beban tersebut, bukan jaminan bahwa website tidak akan pernah down.
Kenapa Ini Penting untuk Bisnis
Bayangkan toko online kamu tiba-tiba viral pagi ini, atau klinikmu masuk berita dan orang ramai-ramai mencari nomor booking. Momen itu datang sekali, dan kalau website down atau lambat saat orang sedang berniat membeli atau booking, mereka tidak menunggu. Mereka pindah ke tab lain, atau ke kompetitor.
Bagi developer, downtime adalah angka di dashboard monitoring. Bagi pemilik bisnis, itu pelanggan yang hilang di detik paling krusial.
Pertanyaan untuk Penyedia Website atau Hosting Kamu
Pertanyaan ini berlaku untuk siapa pun yang mengelola websitemu, termasuk kami:
- Apakah setiap website punya batas sumber daya sendiri, atau berbagi dengan website lain di server yang sama?
- Pernahkah website diuji dengan banyak pengguna bersamaan? Minta hasil tertulis berisi jumlah pengguna, durasi, dan jumlah request yang gagal.
- Apa yang tidak tercakup dalam pengujian itu, misalnya lonjakan mendadak atau serangan?
- Apakah ada cache di depan website, dan apa yang terjadi saat sebuah halaman belum ada di cache?
- Apa yang terjadi pada websitemu saat website lain di server yang sama bermasalah?
Sumber Data dan Cara Kami Mengumpulkannya
Semua angka berasal dari pengukuran internal kami: satu sesi uji k6 (100 pengguna virtual bersamaan, 5,5 menit, 7.688 request) dan pengukuran waktu startup worker pada dua website yang kami kelola, j3companyid.com dan jadiweb.id, sebelum dan sesudah optimasi. Tidak ada audit pihak ketiga, dan kami tidak mengklaim angka uptime jangka panjang dari pengujian ini.
