Post Pic

Stress Test dan Benchmark Aplikasi Web sebelum Sistem LIVE

Ketika Anda berniat melakukan launching atau meluncurkan aplikasi berbasiskan web di Internet, Anda harus mempersiapkan banyak hal. Dari segi sistem salah satunya adalah memastikan aplikasi web yang Anda luncurkan bisa menangani pengakses aplikasi tersebut sejumlah yang Anda targetkan.


Untuk menentukan jumlah pengakses bukanlah hal mudah, tapi Anda bisa melakukan pengujian sebelum live, dengan metoda stress test dan benchmark aplikasi web. Dengan hasil test tersebut, Anda bisa mengetahui performa aplikasi web Anda dan bisa memperkirakan dengan infrastruktur yang Anda miliki sekarang apakah layanan akan berfungsi dengan baik atau tidak saat sistem diluncurkan untuk diakses oleh user.

Stress Test sering Dilupakan

Ketika Anda berniat meluncurkan layanan online berbasiskan web, walaupun itu hanya untuk kalangan terbatas, sebaiknya Anda sudah siap dengan jumlah pengakses yang menjadi target layanan itu. Dan dalam kenyataannya banyak pihak yang lupa atau tidak menghitung dengan baik jumlah pengakses layanannnya.

Sebuah sekolah membuka jalur pendaftaran siswa lewat internet. Jadi dengan tujuan untuk memperlancar proses pendaftaran, orang tua siswa disarankan untuk mendaftar via internet. Harapannya dengan proses pendaftaran online via internet tidak ada lagi antrian di meja pendaftaran ataupun kekisruhan di sekolah gara-gara pendaftar yang banyak.

Singkat cerita, layanan mulai dipublikasikan dan orang tua diinformasikan agar menggunakan layanan pendaftaran online via internet tadi. Hasilnya setelah sistem live, ternyata orang tua siswa kesulitan mengakses layanan online tersebut. Jangankan untuk daftar, baru mengakses form pendaftarannya saja sudah sering timeout. Belum lagi saat submit isian form, bukannya sukses malah muncul halaman error yang tidak dimengerti oleh si orang tua tadi.

Itu adalah contoh peluncuran layanan online yang tidak dipersiapkan dengan baik. Masalah di atas bisa banyak faktor yang menjadikan masalah. Pertama, jumlah pengakses dalam satu saat bersamaan banyak. Kedua, mungkin bandwidth yang disediakan kurang memadai dan terakhir mungkin layanan aplikasinya tidak mampu menangani sejumlah pengakses yang cukup banyak dalam satu saat yang bersamaan.

Seharusnya jika pengembang aplikasi web melakukan proses test sebelum live, masalah kapasitas server atau bandwidth yang tidak memadai sudah harus diketahui jauh-jauh hari sebelum sistem live.

Banyak dan Sedikit itu Relatif

1000 pengakses untuk portal seperti detik atau kompas mungkin sangatlah sedikit, bahkan mungkin tidak terasa apa-apa. Tapi buat aplikasi web yang disimpan di server shared hosting mungkin akan terasa berbeda. Apalagi jika aplikasi web itu dibuat sendiri dan tidak didesain dengan baik, sehingga baru diakses oleh puluhan pengakses dalam satu saat bersamaan sudah tidak responsif lagi, bahkan menjadi error.

Jadi angka-angka bukan ukuran yang baku, tapi dengan target user yang akan menggunakan layanan Anda, Anda bisa memprediksi mana yang harus dicermati lebih lanjut (yang artinya Anda harus melakukan test sistem), mana yang bisa diabaikan.

Misal, Anda diminta membuatkan blog untuk teman Anda sesama mahasiswa. Anda tidak perlu repot-repot melakukan optimasi atau benchmark disana-sini. Dengan konfigurasi standard di sebuah server shared hosting, seharusnya tidak akan ada masalah.

Tapi akan berbeda hasil akhirnya, jika mahasiswa si pemilik blog tersebut adalah seoarang selebritis misalnya. Dan jumlah fansnya ratusan ribu sampai jutaan orang. Dan blog si selebritis itu mendapatkan publikasi dari media yang cukup gencar, maka sudah dipastikan blog itu perlu perhatian lebih khusus terkait pengakses blog itu yang mungkin akan banyak.

Contoh lain yang perlu mendapatkan perhatian lebih, saat sistem akan diluncurkan.

  • Pendaftaran siswa sekolah via internet/online.
  • Pengumuman kelulusan siswa sekolah.
  • Pengumuman atau pendaftaran CPNS (calon pegawai negeri sipil).
  • Pendaftaran ujian saringan masuk ke perguruan tinggi

Sengaja yang saya contohkan seperti di atas, karena berdasarkan pengalaman contoh-contoh di atas lah yang sering gagal melayani usernya saat sistem diluncurkan. Pada umumnya mereka gagal melayani jumlah user yang banyak di satu saat yang bersamaan, walaupun jumlah pengakses banyak itu hanya untuk tempo waktu yang tidak lama.

Sedangkan contoh lain, misalnya peluncuran portal berita internet pada umumnya sudah mempersiapkan menerima lonjakan jumlah pengakses yang banyak, dan didukung oleh infrastruktur yang lebih baik juga.

Stress Test untuk mengukur Kapasitas Sistem

Stress test harus dilakukan secara bertahap. Mulai dengan sejumlah test kecil, lalu dinaikkan nilainya sampai sistem tidak bisa lagi menangani beban yang diberikan. Hal ini penting, karena Anda harus tahu kapasitas sistem yang Anda kelola. Apakah sistem bisa menangani 100 koneksi secara bersamaan, 200 koneksi atau malah baru puluhan koneksi sudah tidak bisa menangani lagi, misalnya.

Jadi test dilakukan tidak serta merta untuk menguji dengan beban yang besar, tapi juga untuk mengukur seberapa banyak beban bisa ditangani oleh sistem.

Aplikasi untuk Stress Test atau Benchmark Web Server

Untuk melakukan pengujian, banyak aplikasi yang bisa digunakan. Misal, ab (Apache Benchmark), siege atau httperf.

Beberapa tulisan di blog ini yang membahas ab dan siege.

Setelah hasil Stress Test didapat

Ini adalah langkah yang paling penting, setelah hasil didapatkan, dan kita mengetahui kira-kira kapasitas sistem yang dikelola, selanjutnya apa yang harus dilakukan.

Jika hasilnya mengecewakan, artinya kapasitas sistem yang Anda kelola dibawah nilai yang Anda harapkan maka langkah selanjutnya adalah melakukan sistem profiling. Mencari tahu bagian mana dari proses aplikasi web Anda yang menyebabkan performa aplikasi menjadi jelek. Lalu perbaiki dan optimasi semuanya sampai mendapatkan nilai yang Anda harapkan.

Selain optimasi konfigurasi, mungkin juga Anda perlu mengupgrade hardware atau bahkan menambah server untuk membagi beban kedalam beberapa server.

Dan setelah semua perbaikan itu dilakukan, lakukan kembali stress test untuk mengetahui kapasitas sistem yang baru Anda optimasi atau baru Anda upgrade/tambah kapasitas hardwarenya.

Tautan


4 Komentar

yansen
24 November 2009

Trima Kasih Artikel anda sangat bermanfaat.

ada yang beberapa hal yang pengin saya tanyakan.

1.menurut anda lebih stabil mana antara Apache dan Nginx?
2.saya akan membuka toko online dengan barang +- 250 ribu barang, nah saya masih bingung untuk menggunakan web server yang mana?
saya lebih familiar dengan Apache, tapi saya lebih suka dengan Nginx..

Bagai mana pendapat anda ?

Salam

yansen

24 November 2009

digabung saja. di depan kasih nginx, set sebagai reverse proxy ke apache. sekalian si nginx itu dipakai utk melayani akses ke file-file statik.

yansen
25 November 2009

brarti pake 2 web server?
apa tidak bentrok kalo 22nya aktif?

waduh saya masih bingung dengan tulisan “nginx itu dipakai utk melayani akses ke file-file statik” maksudnya gimana ? saya masih bingung?

Mohon Pencerahannya..

25 November 2009

ya dijalankan lewat port yang berbeda. seperti saya sebutkan sebelumnya, nginx ada di depan (langsung berhubungan dengan user), dan apache yang benar-benar menjalankan aplikasi webnya (misal pakai php).

silakan baca
http://wiki.nginx.org/NginxHttpProxyModule

tentang konten statik, adalah konten yang bisa langsung diakses (tanpa harus melakukan query ke database misalnya), contohnya: gambar, file css, file javascript dll.

jika masih bingung dengan apa yg sebutkan disini, lebih baik pakai saja yang familiar dengan Anda. optimasi itu diperlukan jika usernya sudah ada, jika loadnya sudah terlihat :)