Hasil Pengujian dan Analisa

Setiap pengujian dilakukan dalam rentang waktu 5 menit. Setelah pengujian selesai

, akan didapatkan data mentah berupa . Berdasarkan data

mentah ini, akan di rata-rata untuk kemudian dimasukkan ke dalam grafik,

Pengujian akan dilakukan 3 kali. Dimulai dari pengujian dengan beban user sebesar 100, lalu dinaikan menjadi 200, dan terakhir menjadi 500 user dalam sekali pengujian. Hal ini dilakukan untuk melihat kinerja server dalam menghadapi berbagai pola trafik data, dengan harapan walaupun server diberi pola beban yang berbeda, hasil yang dikeluarkan tidak berbeda terlalu jauh. Dengan demikian, akan didapatkan data yang lebih akurat.

Akan dilakukan serangkaian pengujian dengan menggunakan rasio beban kerja server default

,

yaitu 1-1

.

Artinya

,

setiap web server akan diperlakukan sama oleh load balancer

,

terlepas dari kemampuan komputasi dari masing-masing web server

.

Sistem pembagian request oleh load balancer akan ditentukan oleh masing-masing algoritma yang sedang berjalan

.

Waktu respon server dilihat dari lamanya proses request permintaan laman web yang dikembalikan oleh server kepada client

.

Proses request dimulai dari saat client men-generate permintaan laman web kepada server (click)

,

hingga direspon oleh server dalam bentuk laman web yang diminta kepada client

.

Output dari proses ini adalah (x) second/click

,

yaitu waktu rata-rata yang diperlukan oleh server untuk menyelesaikan setiap request dalam satuan detik

.

Hasilnya

,

untuk waktu respon server terhadap request 100 user, algoritma Locally-Based Least Connection w/ Replication (LBLCR) memiliki waktu respon tercepat dengan rata-rata waktu respon yang didapat setiap user mencapai 1.47 detik. Algoritma ini memiliki selisih waktu yang lebih cepat 0.01 detik dibandingkan dua algoritma Least Connection, yaitu LC dan WLC. Hal ini disebabkan karena ketiga algoritma ini sebenarnya bekerja dengan algoritma yang sama, namun LBLCR memiliki keunggulan dalam me-manage antrian request dengan menonaktifkan sementara daftar server aktif jika antrian tidak segera dieksekusi oleh server. Poin ini membantu server untuk tidak mengalami overload lebih cepat daripada algoritma lainnya.

Gambar 4

.

2 Waktu respon server beban user 100

Untuk algoritma terlambat terjadi pada Destination Hash (DH) yang memiliki waktu respon 1.61 detik. Algoritma DH menggunakan konsep squid server, dimana server akan diset menyimpan cache data yang menyebabkan setiap request yang masuk akan melewati server tersebut[8].

1.51 1.49 _{1.48 1.48} 1.55 1.47 1.61 1.56 1.51 _1.50 1.53 Beban user 100

Akibatnya, server yang dianggap aktif hanya 1. Walaupun secara teori cache tersebut mempercepat proses pengambilan data, tetapi karena trafik data menjadi 1, maka menjadi tidak efektif jika dibandingkan dengan algoritma lain yang menggunakan 2 server.

Jika dibandingkan dengan pengujian dimana komputer client terhubung langsung ke server tanpa melewati LVS (Tanpa Algoritma), dapat diketahui bahwa waktu responnya tidak berbeda jauh dengan beberapa algoritma LVS. Waktu respon pengujian tanpa algoritma ini hanya terpaut 0.06 detik jika dibandingkan dengan algoritma LBLCR yang memiliki waktu respon tercepat. Dikarenakan pada pengujian ini baru tercapai 100 jumlah user yang mengakses server, maka waktu respon pada sistem single server tanpa menggunakan algoritma masih tidak jauh berbeda dengan waktu respon dengan menggunakan algoritma-algoritma LVS.

Pada pengujian dengan beban user 200, algoritma LBLCR masih menjadi yang tercepat dengan waktu respon sebesar 3.20 detik. Sedangkan untuk respon terlambat terjadi pada saat diujikan pada Point-to-Point. Berdasarkan pada pengujian ini, algoritma LBLCR terbukti masih efektif digunakan untuk meng-handle jumlah user yang tidak terlalu besar. Sedangkan algoritma Destination Hash masih menjadi algoritma terlambat dengan catatan waktu respon mencapai 4.13 detik. Hal ini disebabkan oleh digunakannya setting default pada web server, yaitu dibatasi hanya 150 user yang bisa terkoneksi ke server dalam satu waktu, sehingga menyebabkan

server menjadi lebih cepat overload dengan adanya 200 user yang mencoba terkoneksi secara bersamaan.

Gambar 4.3 Waktu respon server beban user 200

Pada pengujian tanpa algoritma, karena semua request hanya ditangani oleh 1 server saja, maka kemungkinan overload pada server semakin besar, sehingga waktu responnya menjadi lebih lambat 1 detik dari LBLCR. Pada pengujian ini, setting pada Apache Web Server menggunakan setting default juga. Pada setting ini, setiap server hanya dapat menangani 150 thread atau 150 user yang terkoneksi dalam satu waktu. Inilah yang menyebabkan overload lebih besar kemungkinan terjadinya daripada pengujian lewat LVS dengan menggunakan algoritma.

Pada pengujian ketiga dengan beban user 500, terjadi perubahan yang cukup signifikan. DH justru menjadi algoritma tercepat dengan waktu respon 7.66 detik, sedangkan waktu terlama oleh WLC dengan 8.84 detik.

3.26 3.30 3.24 3.21 3.57 3.20

4.13 4.04

3.24 3.27 4.29

Beban user 200

Gambar 4.4 Waktu respon server beban user 500

Dengan diberi beban sebesar 500 user langsung dalam satu waktu, maka setiap server akan menerima masing-masing 250 user dalam satu waktu. Namun karena setting default pada web server hanya membolehkan 150 user saja yang terkoneksi pada satu waktu, maka sisa user yang tidak terkoneksi harus menunggu untuk mendapatkan koneksi dari server. Akibatnya server mengalami overload yang sangat signifikan.

Kondisi ini menyebabkan setiap server memiliki waktu respon yang cukup tinggi, mengingat banyaknya antrian yang terjadi pada pengujian ini. Namun pada algoritma DH, karena menyimpan cache dari halaman web, maka proses pengembalian data pada kepada user menjadi lebih cepat daripada algoritma lain. Pada beban uji kali ini, cara kerja algoritma DH terbukti lebih efektif dalam menangani beban user yang besar.

8.77 8.83 8.47 8.84 8.24 _8.16 7.66 7.87 8.12 8.38 8.53

Beban user 500

Dibandingkan dengan pengujian langsung tanpa melewati LVS atau tanpa algoritma, waktu respon yang didapat masih cukup besar jika dibandingkan dengan pengujian dengan menggunakan LVS. Waktu respon pada pengujian tanpa algoritma hanya berbeda sedikit dengan algoritma RR, WRR, dan WLC. Walau begitu, berdasarkan waktu respon yang didapat, sistem single server tanpa algoritma LVS tidak dapat memberikan waktu respon yang optimal karena waktu respon yang didapatkan cukup besar, dan terjadi perbedaan sebesar hampir 1 detik jika dibandingkan dengan algoritma DH sebagai algoritma dengan waktu respon tercepat.

Berdasarkan ketiga pengujian di atas, maka dapat ditarik kesimpulan sementara bahwa algoritma LBLCR lebih baik dalam meng-handle jumlah user kecil. Sementara untuk jumlah user yang lebih besar, algoritma DH lebih baik dalam menangani jumlah yang besar.

BAB V KESIMPULAN

5.1. Kesimpulan

Berdasarkan hasil penelitian yang telah dilakukan, maka dapat diambil beberapa kesimpulan sebagai berikut :

1) untuk jumlah user 100, waktu tercepat dimiliki oleh algoritma Locally- Based Least Connection w/ Replication atau LBLCR.

2) untuk jumlah user 200, waktu tercepat dimiliki oleh algoritma Locally- Based Least Connection w/ Replication atau LBLCR.

3) untuk jumlah user 500, waktu tercepat dimiliki oleh algoritma Destination Hash atau DH.

5.2. Saran

Ada beberapa saran yang dapat digunakan untuk pengembangan pada penelitian selanjutnya, yaitu :

1) menambahkan fitur keepalived atau heartbeat pada load balancer untuk melihat bagaimana proses pembagian request saat ada pengurangan jumlah web server ditengah proses.

2) menambah jumlah real server.

3) menambah jumlah hardware client yang terhubung untuk melakukan request.

DAFTAR PUSTAKA

[1] Zhang, W. Linux Virtual Server for Scalable Network Services. Tersedia : http://linuxvirtualserver.org/ols/lvs.pdf (Tanggal akses : 13 Februari 2014) [2] Bourke, T. Server Load Balancing. O’Reilly & Associates, Inc:USA. 2001. [3] Horman, S. Linux Virtual Server Tutorial. 2004. Tersedia :

http://www.ultramonkey.org/papers/lvs_tutorial/html/ (Tanggal akses : 13 Februari 2014)

[4] Zhang, W. Job Scheduling Algorithms in Linux Virtual Server. 2011 http://www.linuxvirtualserver.org/docs/scheduling.html/ (Tanggal akses : 18 Februari 2014)

[5] Firdian, F. Macam-macam Server. Tersedia:

http://www.scribd.com/doc/28131016/Macam-Macam-Server (Tanggal akses : 5 Maret 2014)

[6] Webserver Stress Tool User Manual. Paessler.

Tersedia:www.paessler.com/support/manuals (Tanggal akses : 28 Januari 2014)

[7] Huston, G. Measuring IP Network Performance. Telstra. The Internet Protocol Journal-Volume 6, Number 1-Cisco System. 2003. Tersedia:http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj _6-1/measuring_ip.html (Tanggal akses : 25 Juni 2014)

[8] Mack, J. LVS-HOWTO. 2012. Tersedia: http://www.austintek.com/LVS/LVS- HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#DH (Tanggal akses : 28 Agustus 2014)

LAMPIRAN

1. Raw data

1.1. 100 user

 Round Robin

1.2. 200 user

1.3. 500 user