commit to user 18 BAB III
ANALISA KEBUTUHAN DAN PERANCANGAN SISTEM
Berdasarkan hasil observasi dan analisis yang sudah dilakukan maka dihasilkan kebutuhan dan perancangan untuk High Availability server sebagai berikut:
Spesifikasi Perangkat
Perangkat perangkat yang digunakan pada penelitian ini dibagi menjadi 2 jenis yaitu hardware dan software
3.1.1 Spesifikasi hardware
Untuk perangkat yang digunakan dalam penelitian ini penulis menggunkan
Virtual machine yang berada pada suatu host VMware hypervisor dengan
spesifikasi sebagai berikut: 1. Host VMware ESXi
Manufacture : Cisco System Inc
Model : UCSC-BASE-M2-C460
CPU Cores : 40 CPUs x 2.393 GHz
Processor Type : Intel(R) Xeon(R) CPU E7-4870 @ 2.40 GHz VMware version : ISXi-5.5.0-1331820-standard
Memory : 130921.30 MB
Storage : 1630 GB
2. Spesifikasi virtual mechine
CPU : 1 vCPU @ 2.393 GHz
Memory : 2048 MB
Storage : 300 GB Thin Provision Network Adapter : 1 x E1000 1GB/s
commit to user 3.1.2 Spesifikasi Software
Semua server pada penelitian ini menggunakan operating sistm yang sama yaitu FreeBSD 10.0 amd64. Perangkat lunak yang digunakan dalam penelitian ini pada masing masing server adalah sebagai berikut :
1. Load Balancer, aplikasi yang di install adalah HAproxy 1.4 dan CARP 2. Web server, aplikasi yang di install adalah PHP 5.6 dan nginx 1.6.2 3. Database server, aplikasi yang di install adalah Mysql 5.0 dan CARP 4. File server, aplikasi yang di install adalah NFSd
5. Server tester aplikasi yang di install adalah HTTPerf Jalannya Penelitian
Skema yang dijalankan pada pembuatan High Availabity Server ini seperti gambar berikut:
Skema Penelitian
Penjelasan skema dari jalannya penelitian seperti pada gambar 3.1 yaitu sebagai berikut:
1. Pengambilan data
Data data yang dibutuhkan yaitu berkaitan dengan kebutuhan dan kendala - kendala yang ada pada system suatu web server seperti :
- Web server jika menangani request yang banyak sering kali down - Jika terjadi maintenance pada webserver pasti website down karena
server hanya ada Satu
- Jika terjadi masalah hardware pada database khususnya harddisk maka data yang ada didalamnya akan sulit untuk didapatkan lagi
commit to user
- Meskipun hardware server yang digunakan mempunyai spesifikasi yang besar, tetapi jika terjadi sesuatu misal harus reboot maka web
site pasti juga mengalami down.
2. Analisa Data
Proses pengecekan semua data yang telah ada yang nantinya digunakan untuk membuat perencanaan terhadap sistem
3. Perencanaan
Setelah semua data yang diperlukan terkumpul kemudian dibuat perencanaan untuk pembuatan sistem seperti topologi yang akan digunakan aplikasi yang akan dipakai
4. instalasi dan konfigurasi
Proses pembuatan sistem yang didalamnya meliputi instalasi hardware dan software dalam bentuk percobaan.
5. Evaluasi
Evaluasi dilakukan untuk mengecek apakah semua komponen yang ada pada sistem sudah berjalan seperti yang direncanakan. Apabila masih terdapat kekurangan pada sistem akan diperbaiki kembali ke skema analisa data
6. Tes Akhir
Tes dilakukan untuk memastikan sistem sudah melakukan fungsinya dengan baik. Pengujian yang dilakukan adalah
- Pengujian performa dengan parameter Thoughput - Pengujian performa dengan parameter Response time - Pengujian performa dengan parameter reply sukses - Pengujian failover
- Pengujian redundansi database 7. Implementasi
Implementasi dilakukan apabila sistem High Availability web server sudah beralan dan siap produksi
8. Dokumentasi
commit to user Perancangan Sistem
Berdasarkan pengambilan data dan mencari kebutuhan informasi maka perancangan High Availability server sebagai berikut:
LOAD BALANCER 01 WEB 01 WEB 02 DATABASE 01 DATABASE 02 FILE SERVER LOAD BALANCER 02 VIRTUAL IP VIRTUAL IP INTERNET
Rancangan High Availability
Dari gambar 3.2 diatas rancangan High Availability Server dibagi menjadi 3 tahap yaitu:
3.3.1 Perancangan load balance server
Semakin banyak pengguna yang mengakses web site maka semakin berat pula kerja web server. Karena, web server harus dapat menjawab semua permintaan tersebut tanpa ada yang tertolak. Untuk memenuhi permintaan tersebut maka web server harus memiliki performa yang handah. Untuk memperoleh performa yang handal maka web server harus memiliki resource yang besar pula, tetapi untuk mendapatkan sesource yang besar memerlukan biaya yang sangat besarpula. Terlebih lagi kalau hanya dengan satu server saja jika terjadi kerusakan baik pada sisi hardware atau pun software dari server tersebut maka service tersebut akanberhenti.
Akibatnya informasi yang dimiliki tidakakan tersebar dengan kata lain
web site akan down atau mati. Untuk mengantisipasi kerusakan tersebut
commit to user
dari server yang down tadi. Dengan demikian waktu hidup web server menjadi meningkat. Akan tetapi kembali ke biaya lagi, untuk mendapatkan
resource yang besar saja harus memerlukan biaya yang sangat besar apalagi
harus menyediakan backup yang memiliki resource yang sama. Terlebih lagi resource yang ada pada server backup sedikit kurang bermanfaat karena hanya digunakan saat server utama mati saja. Untuk mengatasi hal tersebut maka dapat menggunakan sistem load balance.
Skema load balance
Load Balance disini berfungsi untuk membagi permintaan dari pengunjung untuk ditangani oleh lebih dari satu server dengan katalain resource yang ada pada beberapa server tersebut akan terpakai semua dan bisa di katakan di kombinasikan atar kedianya untuk mempeoleh performa yang tinggi.
Request yang datang dari pengunjung akan diarahkan ke load balancer
baik dengan domain ataupun alamat ip kemudian Load balance akan membagi request tersebut ke server - server yang telah di alokasikan dengan algoritma yang digunakan seperti pada gambar 3.3. Algoritma atau metode yang dapat digunakan dalam load balance sangatlah beragam seperti Round
Robin, lease connection, source, URL, DNS round robin, random allocation dan masih banyak lagi.
commit to user 3.3.2 Perancangan failover
Dalam mengimplementasikan High Availability web server, redundansi adalah hal yang wajib di terapkan untuk membuat sistem tersebut mempunyai uptime yang tinggi. Redudansi dibutuhkan di semua bagian sistem mulai dari listrik yang harus memiliki lebih dari dua sumber (redundant) untuk membuat mesin selalu menyala, selain itu di sisi network juga harus redundanyaitu memiliki lebih dari satu jalur, Load balancer-pun juga harus begitu lebih dari satu.
Dalam penenelitian ini untuk mengimplementasikan failover tersebut pada load balancer penulis menggunakan ip virtual. Dalam FreeBSD untuk membuat ip virtual dapat menggunakan CARP interface.
Skema failover
Seperti pada gambar 3.4 load balancer server dipasang CARP interface
yang memiliki satu alamat ip yang sama, kemudian salah satunya ditunjuk sebagai master dan sisanya sebagai slave. Server yang bertindak sebagai
master akan menangani semua traffic yang menuju ke ip virtual tadi. Ketika server master mati maka secara otomatis server yang slave akan
menggantikan posisi master yang down kemudian status pada server yag
commit to user 3.3.3 Perancangan redudansi databases
Dalam redudansi database tidak hanya berfungsi sebagai backup saja tetapi juga berfungsi sebagai failover. Selain itu yang paling penting adalah data yang ada di dalamnya harus selalu sama antar keduanya. Terlebih lagi saat salah satu server database mati, selain menjaga agar update data tetap berjalan tanpa merubah setingan dari sisi aplikasi, database server yang mati tadi dipastikan saat hidup bisa melakukan sinkronisasi data dengan
server database yang masih menyala.
commit to user 25
BAB IV
IMPLEMENTASI DAN ANALISA HASIL
Berdasarkan Perancangan pada pembuatan High Availability Server maka dilakukan pengimplementasian dan analisa untuk mengecek fungsi dari masing - masing bagian sebagi berikut:
Topologi jaringan
Berikut adalah gambaran scema high availability server yang akan dibangun: LOAD BALANCER 01 10.10.20.101 WEB 01 10.10.20.103 WEB 02 10.10.20.104 DATABASE 01 10.10.20.108 DATABASE 02 10.10.20.109 FILE SERVER 10.10.20.107 LOAD BALANCER 02 10.10.20.102 VIRTUAL IP 10.10.20.110 VIRTUAL IP 10.10.20.100 INTERNET
Skema High Availability
Pada Gambar 4.1 merupakan gabungan dari loadbalancer, failover, dan replikasi dan redundansi database
LOAD BALANCER 01 10.10.20.100 10.10.20.101 WEB 01 10.10.20.103 WEB 02 10.10.20.104 DATABASE 01 10.10.20.110 10.10.20.108 DATABASE 02 10.10.20.110 10.10.20.109 FILE SERVER 10.10.20.107 LOAD BALANCER 02 10.10.20.100 10.10.20.102 switch INTERNET Router gateway 10.10.20.1
commit to user
Pada gambar 4.2 semua server terletak pada satu jaringan yang sama dan memepunyai ip address yang satu network untuk mempermudah dan mempercepat koneksi antar server.
Instalasi Server
Dalam subbab ini dijelaska proses instalasi semua server yang nantinya menjadi bagian dari system ini. Skema instalasi yang dilakukan adalah
FreeBSD 10.0 CARP Nginx 1.6.2 NFSd File server Php 5.6 & php-extension 5.6 server Hardware HAProxy 1.4.25 MySQL-Server 5.6 MySQL Replication
NFS Client Web Server Database
Server Loadbalancer
Server
Httperf Tester server
Skema Instalasi
Gambar 4.3 merupakan langkah instalasi yang dilakukan untuk membuat server sesuai dengan fungsi masing masing.
Seluruh server yang digunakan menggunakan Operating system yang sama yaitu FreeBSD RELEASE 10.0 yang dapat di unduh di situs resminya
http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/FreeBSD-10.0-RELEASE-amd64-dvd1.iso.
Proses instalasi FreeBSD 10.0 dilakukan sama seperti sistem operasi lain Linux dan Windows, langkah pertama dimulai dengan proses booting dari compact disk/flashdisk. Tampilan awal booting seperti pada gambar 5.1
Proses instalasi tidak menggunakan mode GUI (Graphic User Interface) namun instalasi digunakan mode text dikarenakan prosesnya yang lebih cepat dan mudah. Instalasi dimulai ketika muncul bootloader seperti pada gambar 4.4.
commit to user
Booting instalasi FreeBSD10.0
Instalasi dilanjutkan dengan menekan tombol Enter, maka muncul pilihan Install seperti pada gambar 4.5
Menu instalasi FreeBSD 10.0
Pilih Install dipergunakan ketika sistem ingin dipasang sistem operasi FreeBSD. Pilih Shell dipergunakan apabila ingin repair/perbaiki sistem operasi dan pilih Live CD digunakan bila ingin mencoba sistem operasi tanpa melakukan instalasi pada hardisk.
commit to user
Setelah proses instalasi selesai setting ip dan domain sesuai dengan topologi yang telah dibuat. Untuk memastikan ip yang terkonfigurasi sudah benar atau salah lakukan ping ke google.com dan update ports pada freebsd untuk memperbarui list-list aplikasi yang dapat diinstall di operatingsistem freeBSD. Setelah semua konfigurasi dasar sudah terseting di semua server, tingggal proses instalasi aplikasi untuk masing masing bagian adalah sebagai berikut:
Pada pembuatan webserver instalasi aplikasi yang diperlukan adalah 1. Instalasi nginx 1.6.2 sebagai webserver
2. Instalasi php 5.6 dan php 5.6 extension sebagai bahasa pemrograman untuk membuat website
3. Mounting NFS yang digunakan untuk file-file web site untuk memastikan semua web server mempunya file yang sama
Pada pembuatan Loadbalancer instalasi aplikasi yang dilakukan adalah 1. Mengedit kernel dengan menambahkan modul baru yaitu CARP
2. Memastikan carp sudah terpasang dengan perintah sysctl net.inet.carp jika sudah terpasang akan tampil informasi tentang carp yang telah ada
3. Instalasi HAProxy 1.4.25 sebagai aplikasi loadbalancer
Pada pembuatan database instalasi aplikasi yang dilakukan adalah 1. Mengedit kernel dengan menambahkan modul baru yaitu CARP
2. Memastikan carp sudah terpasang dengan perintah sysctl net.inet.carp jika sudah terpasang akan tampil informasi tentang carp yang telah ada
3. Instalasi MySQL server 5.0 sebagai database
Pada pembuatan NFS server tidak perlu melakukan instalasi apapun karena secara default freebsd sudah terinstall nfs tinggal diaktifkan saja.
Untuk server untuk melakukan testing aplikasi yang diperlukan adalah httperf yang digunakan untuk testing performa webserver.
commit to user Konfigurasi Aplikasi Server
4.3.1 Konfigurasi Webserver
Pada web server penulis hanya menggunakan konfigurasi default yang sedah ada, yang perlu ditambahkan adalah konfigurasi penghubung antara nginx dengan php agar nginx dapat mengenali file dengan ekstensi php. Konfigurasi yang ditambahkan adalah
Pengaktifan modul php pada nginx
Nginx dan php-fpm perlu diseting berjalan otomatis ketika booting computer sehingga pengguna server tidak selalu manual menjalankan service. Sisipkan script nginx_enable=YES” dan php_fpm_enable="YES" ke file /etc/rc.conf seperti berikut:
seting startup aplikasi
Untuk menjalankan service - service yang telah dikonfigurasi dengan menggunakan perintah
menjalankan nginx dan php-fpm
Untuk mengecek apakah web server sudah benar dengan membuat file php dengan didalamnya berisikan
php info location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME/usr/local/www/nginx$fastcgi_scrip include fastcgi_params; }
# echo ‘nginx_enable=”YES”’ >> /etc/rc.conf # echo ‘php_fpm_enable=”YES”’ >> /etc/rc.conf
# /usr/local/etc/rc.d/nginx start # /usr/local/etc/rc.d/php-fpm start
<?php
Phpinfo(); ?>
commit to user
Jika web server sudah terkonfigurasi dengan benar maka jika membuka file php dibrowser maka web server akan mengeksekusi script php kemudian dikonvert menjadi sebuah file html yang kemudian dibaca oleh web browser. Untuk script diatas jika browser melakukan request maka akan tampil seperti pada gambar 4.10
Tampilan web server 4.3.2 Konfigurasi Failover
Dalam membuat system failover penulis menggunakan CARP pada freebsd unutk membuat pseudo devices yang diguanakan sebagai ip virtual. Konfigurasi dimulai dengan merubah kernel pada freebsd, yaitun dengan menduplikat file konfigurasi kernel dengan perintah
Kostum kerner
File NETMON di tambahkan option carp. Setelah itu config dan install NETMON tersebut dengan perintah
Instalasi kernel
Setelah selesai melakukan perubakan pada kernel maka server perlu melakukan reboot untuk merefrash kembali system. Untuk mengecek
# cd /usr/src
# make buildkernel KERNCONF=NETMON # make installkernel KERNCONF=NETMON
# cd /usr/src/sys/amd64/conf # cp GENERIC NETMON
commit to user
apakah CARP interface sudah terinstall menggunakna perintah Sysctl net.int.carp maka akan muncul
Status CARP
Kemudian untuk membuat ip virtual dengan merubah pada file
/etc/rc.conf. Konfigurasi dilakukan di kedua serever sebagai contoh pada server 1 di konfigurasi sebagai berikut:
Konfigurasi CARP loadbalancer 1
Kemudian untuk konfigurasi pada server 2 adalah sebagai berikut
Konfigurasi CARP loadbalancer 2
Pada konfigurasi diatas dapat dilihat bahwa server 1 mempunyai ip management 10.10.20.101 dan server 2 mempunyai ip management 10.10.20.102 dengan keduanya mempunyai satubuah ip yang sama yaitu 10.10.20.100 yang sering disebut sebagai ip virtual. Dari kedua konfigurasi tersebut dapat dilihan server 1 nantinya akan menjadi master, karena pada
server 1 mempunya advskew yang lebih kecil dari pada server 2, secara
default jika advskew tidak dituliskan maka akan memiliki nilai 0 semakin kecil advskewnya maka memiliki prioritas yang semakin besar. Untuk menjalankannya lakukan restart network dengan perintah
Perintah restart network dan routing
# sysctl net.inet.carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.demotion: 0 hostname="lb01.netmon.local" ifconfig_em0="inet 10.10.20.101 netmask 255.255.255.128"
ifconfig_em0_alias0="vhid 1 pass rahasia alias 10.10.20.100/24"
hostname="lb02.netmon.local"
ifconfig_em0="inet 10.10.20.102 netmask 255.255.255.128"
ifconfig_em0_alias0="vhid 1 advskew 100 pass rahasia alias 10.10.20.100/24"
commit to user
Setelah berhasil maka akan muncul interface vhid yang dapat dilihat dengan perintah ifconfig maka diperoleh hasil
Interface status server 1
interface status server 2
Dari gambar 4.6 dapat dilihat interface carp sertindak sebagai master dan pada server 2 carp interface bertindak sebagai backup.
4.3.3 Konfigurasi Database Server
Aplikasi yang digunakan dalam membuat system redudansi
database ini adalah mysql dan carp interface dimana konfigurasi pada carp
seperti pada subbab sebelumnya carp interface di gunakan untuk failover
database dan untuh sinkronisasi database menggunakan salah satu fasilitas
yang ada pada mysql yairu mysql replikasi.
Konfigurasi yang dilakukan adalah dengan menambahkan server id dan mengaktifkan log-bin pada file konfigurasi mysql yaitu my.cnf yang terletak pada folder /usr/locat dengan perintah
Konfigurasi mysql
Nilai server id harus berbeda pada setiap server. Dengan mengaktifkan log-bin maka secara otomatis mysql akan membuat file baru
# echo ‘server-id = 1’ >> /usr/local/my.cnf # echo ‘log-bin’ >> /usr/local/my.cnf
commit to user
pada directory mysql pada freebsd defaultnya terletak di /var/db/mysql disitu akan muncul file log-bin dengan nama namadatabase-bin.000001, sebagai contoh pada database db02 maka akan membuat file log-bin dengan nama db02-bin.000001 yang berisikan log query pada database db02. Log ini nantinya akan dibaca oleh database slave untuk melakukan replikasi.
Untuk menjalankan relikasi hal yang harus dilakuakan yaitu 1. Membuat user yang nantinya digunakan untuk replikasi user tersebut
diberi privileges replication langkah yang dilakaukan adalah dengan masuk ke mysql kemudian dengan perintah
Perintah masuk kedalam mysql
Kemudin masukkan password user root. Setelah masuk perintah untuk menambahkan user dan memberi privileges replication pada user trersebut adalah
Konfigurasi user replikasi
Perintah tersebut berarti memberikan privileges SELECT, RELOAD, SUPER, dan REPLICATION SLAVE pada semua table di semua database kepada user replica 03 yang login darimanapu dengan password passw0rd. Jika user replica03 belum ada pada
database maka secara otomatis akan dibuat
2. Mengubah master database yang semula dirinya sendiri kemudian diubah ke server yang lain yang bertindak sebagai master. Sebagai contoh db03 akan mengubah masternya menjadi db02. Artinya db03 sebagai slave dari db02. Sebelum merubahnya db03 harus tahu
master status pada db02 terlebih dahulu. Untuk melihat master status
pad db02 di gunan perintah Show master status pada mydql db02
# mysql –u root –p
Mysql > GRANT SELECT,RELOAD,SUPER,REPLICATION SLAVE ON *.* TO 'replika03'@'%' IDENTIFIED BY
commit to user
master status db02
Setelah tahu file log-bin dan posisinya kemudin pada db03 dilakukan konfigurasi
konfigurasi slave mysql
Setelah delesai dapat dilihat status slave pada db03 dengan perintah
show slave status; pada msql
slave status database db03
Dari gambar 4.9 dapat dilihat slave_io_state yang bernilai waiting
for master to sent event artinya server db03 sudah siap menjadi slave
tinggal menunggu update dari master yaitu db02.
Mysql > CHANGE MASTER TO MASTER_HOST = 'db02', MASTER_USER = 'replika03', MASTER_PASSWORD = 'passw0rd', MASTER_LOG_FILE = 'mysql-bin.000012', MASTER_LOG_POS=1935579; Mysql > START SLAVE;
commit to user
Setelah konfigurasi slave pada db03 kemudian dilakukan ha yang sama pada server db02. Untuk memastikan replikasi yang dibuat sudah berhasil atau belum dilakukan dengan cara menambahkan data pada salh satu server dan kemudian dilihat pada server yang lainnya apakah ikut bertambah atau tidak. Percobaan dilakukan di kedua server database Pengujian dan Analisa
4.4.1 Skema pengujian
Pengujian yang dilakukan ada dua jenis pengujian yaitu pengujian terhadap availability atau ketersedian dan pengujian terhadap performa
Pengujian terhadap availability dilakukan dengan cara mematikan salah satu komponen yang ada pada salah satu system dengan menggunakan topologi high availability seperti pada gambar 4.1 dengan hasil yang natinya didapat adalah apakah website masih bisa di akases atau tidak dan data yang pada databases dapat sinkron atau tidak
Pengujian terhadap performa dilakukan dengan menggunakan server tester yang menggunakan aplikasi httperf yang berfungsi untuk mengirimkan request ke webserver. Pengunjian yang dilakukan untuk membandingkan performa antara satu server dengan dua server dengan topologi sebagai berikut:
1. Topologi 1
Pengujian yang dilakukan pada topologi pertama adalah dengan melakukan testing langsung kepada webserver 1 tanpa adanya loadbalancer, dengan topologi sebagai berikut
WEB SERVER 1 TESTER
commit to user 2. Topologi 2
Pengujian pada topologi 2 dilakukan dengan cara melakukan testing langsung pada web serever 2 dengan topologi seperti pada gambar 4.26
WEB SERVER 2 TESTER
Topologi testing 2 3. Topologi 3
Pada topologi 3 pengujian dilakukan dengan cara tester melakukan pengujian terhadap load balancer server yang menangani 2 buah web server di bawahnya dengan topologi sebagai berikut
LOAD BALANCER WEB SERVER 1 WEB SERVER 2 TESTER Topologi testing 3 4. Topologi 4
Pada topologi 4 pengujian dilakukan dengan cara tester melakukan pengujian terhadap web server 1 yang sudah terhubung dengan file server dan database server. Topologi yang di ujikan adalah sbagai berikut
commit to user WEB SERVER 1 DATABASE 01 DATABASE 02 FILE SERVER VIRTUAL IP TESTER Topologi 4 5. Topologi 5
Pada topologi 5 pengujian dilakukan dengan cara tester melakukan pengujian terhadap web server 2 yang sudah terhubung dengan file server dan database server. Topologi yang di ujikan adalah sebagai berikut WEB SERVER 2 DATABASE 01 DATABASE 02 FILE SERVER VIRTUAL IP TESTER Topologi 5 6. Topologi 6
Pada topologi 6 pengujian diarahkan ke loadbalancer yang menggunakan 2 web server yang sudah terhubung dengan file server dan databases server ddengan topologi adalah sebagai berikut
commit to user LOAD BALANCER 01 WEB 01 WEB 02 DATABASE 01 DATABASE 02 FILE SERVER LOAD BALANCER 02 VIRTUAL IP VIRTUAL IP TESTER Topologi 6
Pengujian load balancer penulis melakakukan 3 kali pengujian 1 server dan 5 kali pengujian 2 server yang dilakukan dengan jeda waktu 1 jam antar pengujian, yang diasumsikan dengan jeda waktu tersebut server dapat kembali normal setelah diberikan beban yang berat. Parameter yang digunakan untuk melakukan pengujian adalah Troughput, Response Time, dan Error dengan mengirimkan 10000 request dengan rate 200, 400, 700, 1000, 1500, 2000, 2500, dan 3000 request per detik.
Pengujian menggunakan perangkatlunak httperf. Web server. Pengujian dilakukan dengan perangkat lunak httperf. Perangkat lunak ini dapat menciptakan banyak request dan koneksi dalam satu waktu. Parameter yang digunakan pada pengujian menggunakan httperf adalah sebagai berikut:
Perintah pengujian performa
Perintah di atas menginstruksikan httperf untuk menguji web server dengan alamat netmon.local/index.php. Perintah --num-conn 10000 menginstruksikan httperf untuk menyediakan 10000 request, perintah --rate 100 menetapkan httperf untuk membuat 100 request baru per detik,
perintah--timeout 10 mengatur waktu time out sebesar 10 detik, setiap permintaan yang
tidak direspon dalam rentang waktu ini akan dianggap sebagai error.
#httperf server netmon.local uri /index.php num-conn 10000 --rate 100 --timeout 10
commit to user 4.4.2 Parameter Throughput
Parameter throughput pada penelitian ini mewakili sejumlah request yang dapat direspon oleh web server pada satu waktu. Parameter ini dihitung dalam satuan KB/second. Semakin besar nilai dari parameter ini, maka semakin baik pula kinerja dari web server tersebut.
Hasil Uji Parameter Throughput rate
Req/sec
Rata-rata Troughput/req Topologi 1 Topologi 2 Topologi 3
200 84.591 84.716 84.637 400 60.350 59.718 84.620 700 32.091 32.946 68.749 1000 21.552 21.392 46.804 1500 13.352 12.953 29.022 2000 9.144 8.819 21.125 2500 6.586 6.319 15.815 3000 5.305 5.128 11.223 Rata-rata 29.121 28.999 45.249
Tabel 4.1 menunjukkan perbandingan troughput antara webserver 01,
webserver 02, dan kedua webserver dengan loadbalancer. Dari Tabel 4.1
tersebut dapat dibuat grafik sebagai berikut.
Grafik Perbandingan Troughput 0.000 10.000 20.000 30.000 40.000 50.000 60.000 70.000 80.000 90.000 200 400 700 1000 1500 2000 2500 3000
Troughput
Topologi 1 Topologi 2 Topologi 3
RateRequest (req/s) Tro u gh p u t( KB/ s)
commit to user
Dari grafik pada gambar 4.32 menunjukakan trougput berbanding terbalik dengan jumlah request semakin banyak jumlah request yang di terima maka semakin kecil througput yang dapat ditangan oleh web server. Webserver1 dan Webserver2 memilik grafik troughput yang sama karena mempunyai resource yang sama pula. Berbeda dengan 2server yang menggunakan loadbalancer memiliki troughput yang lebih tinggi karena memiliki resource yang lebih besar yaitu gabungan dari webserver1 dan webserver2. Jika dirata-rata maka peningkatan troughput dari 1 server ke 2 server adalah sebesar 55 %.
4.4.3 Parameter Response Time
Parameter Respose Time Parameter response time pada penelitian ini menggambarkan kecepatan web server dalam menanggapi request dari client. Parameter ini dihitung dalam satuan milisecond. Semakin kecil nilai dari parameter ini, maka semakin cepat sebuah web server dalam menanggapi request dari client. Hasil dari pengamatan parameter response time pada penelitian ini, seperti pada tabel 4.2
Hasil Uji Parameter Response Time rate
Req/sec
Rata-rata Response Time/req Topologi 1 Topologi 2 Topologi 3
200 0.021 0.021 0.023 400 1.210 1.212 0.011 700 0.417 0.410 0.757 1000 0.211 0.207 0.393 1500 0.098 0.097 0.182 2000 0.058 0.057 0.106 2500 0.041 0.040 0.078 3000 0.030 0.030 0.059 Rata-rata 0.261 0.259 0.201
Tabel 4.2 menunjukkan perbandingan dari response time antara
webserver 01, webserver 02, dan kedua webserver dengan loadbalancer yang
dihasilkan pada penelitian ini. Dari data diatas dapat dibuat grafik sebagai berikut:
commit to user
Grafik Perbandingan Response Time
Pada gambar 4.33 menunjukkan grafik perbandingan response time antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer. Dari grafik tersebut response time antara server1 dan server 2 memiliki nulai yang hampirsama dengan titik tercepat pada connection yang mempuyai rate di bawah 200req/s. Sedang yang menggunakan 2 server dengan loadbalancer mempunyai responstime tercepat sampai dengan rate 400 req/s. setelah titik tersebut server mulai dipaksa bekerja lebih, karena server tidak kuat dengan rate diatas 200 req/s maka dari situlah mulai terjadi antrian karena terjadi antrian maka responstime yang dihasilkan akan menjadi tinggi.
Puncak responstime tertinggi pada 1 server yaitu antara rate 200 req/s sampai rate 400 req/s, sedangkan untuk yang 2 server adalah rentang 400 req/s sampai 700 req/s. pada titik puncak itu server mulai terjadi error pada saat menangani request. Semakin banyak rate yang diberikan maka semakin banyak pula error yang terjadi sehingga request yang direply sukses semakin turun karena itulah responsetime yang diberikan mulai mengecil karena semakin sedikit reply sukses yang di hasilkan.
Jika dilihat responstime dengan rate lebihdari 700 request/second 1 server memiliki respons yang lebih baik daripada 2 server yang menggunakan load balancer. Akan tetapi jika dilihat dengan reply sukses yang dihasilkan 2
0.000 0.200 0.400 0.600 0.800 1.000 1.200 1.400 200 400 700 1000 1500 2000 2500 3000
Response Time
Topologi 1 Topologi 2 Topologi 3
Rate Request (req/s)
Respo n se Tim e( m s)
commit to user
server dengan load balancer lebih banyak 2 kalilipat dibandingkan dengan menggunakan 1 server karena reply sukses yang dihasilkan besar itu mengakibatkan response time yang dihasilkan lebih besar
4.4.4 Parameter Reply Sukses
Parameter Reply sukses pada penelitian ini menggambarkan banyaknya
reply sukses yang terjadi pada saat web server menanggapi request dari client.
Semakin besar nilai dari parameter ini, maka semakin baik kinerja sebuah web
server dalam menanggapi request dari client dan semakin besar nilai dari
parameter ini maka semakin kecil reply error yang dihasilkan Hasil dari pengamatan parameter error pada penelitian ini, seperti pada tabel 4.3
Hasil Uji Parameter Reply sukses
rate Req/sec
Reply sukses (req)
Topologi 1 Topologi 2 Topologi 3
200 10000.0 10000.0 10000.0 400 7286.0 7187.0 10000.0 700 3909.3 4048.0 8478.3 1000 2651.3 2613.0 5864.7 1500 1662.7 1645.0 3738.0 2000 1146.7 1124.0 2772.0 2500 835.0 845.0 2134.7 3000 675.7 659.0 1776.7 Rata-rata 3520.8 3515.1 5595.5
Tabel 4.3 menunjukkan perbandingan dari reply suskes antara webserver 01, webserver 02, dan kedua webserver dengan loadbalancer yang dihasilkan pada penelitian ini. Dari data diatas dapat dibuat grafik sebagai berikut:
commit to user
Grafik Perbandingan reply suskes
Dari grafik gambar 4.34 menunjukkan semakin banyak request rate yang diberikan ke webserver maka semakin kecil reply sukses yang diberikan web
server. Dari 10000 request yang diberikan pada percobaan dengan rate yang
berbeda, web server yang hanya dengan 1 server dapat mengembalikan sebua
requs yang diberik sampai dengan rate 200 req/s sedangkan untuk webserver
yang menggunakan loadbalancer 2 server dapat mereply semua request sampai dengan rate 400 req/s setelh batas tersebut mulai terjadi error pada sisi webserver karena tidak sanggup menangani request dengan kecepatan lebih dari batas tersebut diatas. Dari rata-rata pad percobaan dengan parameter reply sukses maka peningkatan reply sukses dari 1 server menjadi 2 server sebesar 60%.
4.4.5 Konsumsi Sumberdaya
Pada subbab ini menjelaskan tentang resource yang digunakan saat dilakukan pengujian performa seperti CPU dan Memory. Penelitian yang dilakukan adalah membandingkan resource yang di konsumsi saat server menerima request dengan rate request yang berbeda. Ada dua nilai yang diambil yaitu CPU Load dan pertambahan memory yang digunakan.
Pada percobaan terhadap topologi 1 sumberdaya yang dikonsumsi oleh Webserver 1 adalah seperti table berikut
0.0 2000.0 4000.0 6000.0 8000.0 10000.0 12000.0 200 400 700 1000 1500 2000 2500 3000
Reply sukses
Topologi 1 Topologi 2 Topologi 3
Reply
(req)
commit to user
Tabel penggunaan sumberdaya pada topologi 1
Request web server 01 CPU (%) Memory (Kb) 200 73.00 0 400 100.00 1924 700 100.00 1924 1000 100.00 1924 1500 100.00 1924 2000 100.00 1924 2500 100.00 1924 3000 100.00 1924
Dari table diatas dapat di jelaskan bahwa webserver 01 ketika menangani request dengan rate 200 request per second dapat ditangani dengan mudah karena cpu yang dibutuhkan untuk menangani request tersebut belum sepenuhnya terpakai, yang terpakai hanya 73 % dari cpu yang dimiliki dan juga tidak memakan memory. Untuk rate request 400 sampai 300 req/s web server 01 kualahan untuk menangani request tersebut, hal itu dapat dilihat dari load cpu yang digunakan yaitu 100% hal tersebut dapat menyebabkan reqest yang diterima tidak semuanya dapat dibalas dengan sukses seperti yang di jelaskan di subbab sebelumnya. Sedangkan konsumsi untuk konsumsi memory web server tidak terlalu membutuhkan memory hal itu dapat dilihat dari penggunaan memory hanya sebesat 1924 Kb atau hamper 2 Mb saja.
Percobaan yang dilakukan terhadap topologi 2 yaitu langsung kepada web server 02 diperoleh hasil sebagai berikut
Tabel penggunaan sumberdaya pada topologi 2
Request web server 02 CPU (%) Memory (Kb) 200 74.00 0 400 100.00 1920 700 100.00 1920 1000 100.00 1920 1500 100.00 1920 2000 100.00 1920 2500 100.00 1920 3000 100.00 1920
commit to user
Pada topologi 2 atau percobaan terhadap webserver 02 sumberdaya yang dibutuhkan tidak jauh berbeda dengan web server 01 hal itukarena resource yang dimiliki, aplikasi yang digunakan, dan load yang diterima sama persis antar keduanya.
Percobaan yang dilakukan pada topologi 3 yaitu dua server yang di load balance diperoleh hasil sebagai berikut
Tabel penggunaan sumberdaya pada topologi 3 Request
web server 01 web server 02 Load balancer
CPU (%) Memory (Kb) CPU (%) Memory (Kb) CPU (%) Memory (Kb) 200 45.00 0 40.00 0 30.00 0 400 80.00 0 75.00 0 50.00 0 700 100.00 1924 100.00 1920 65.00 0 1000 100.00 1924 100.00 1920 65.00 0 1500 100.00 1924 100.00 1920 60.00 0 2000 100.00 1924 100.00 942 65.00 0 2500 100.00 1924 100.00 0 65.00 0 3000 100.00 0 100.00 0 75.00 0
Dari table 4.6 diperoleh hasil untuk semua percobaan dengan rate yang berbeda-beda load balancer masih kuat untuk menangani request yang datang kemudian di teruskan ke webserver maksimum sumberdaya yang dikonsumsi adalah 75 % dari sumberdaya yang ada yaitu pada rate 3000 req/s. load balancer tidak membutuhkan memory untuk melakukan pembagian request hal itu dapat dilihat dari data yang telah diperoleh untuk semua rate yang diterima pertambahan load memory pada server sebesar 0 Kb. Dari data tersebut berarti load balancer tersebut masih bisa menangani request dengan rate yang lebih besar lagi.
Untuk sumberdaya CPU yang dikonsumsi web server pada hakikatnya sama dengan percobaan di topologi 1 maupun di topologi 2 satu server dapat menangani request dengan rate 200req/s tanpa ada masalah, sedangkan pada rate 400 req/s server mulai kualahan untuk menangani. Di topologi 3 ketika rate yang datang sebesar 200 req/s maka request tersebut akan dibagi ke kedua server dengan katalain 100 req/s menuju web server 1 dan 100 req/s menuju web server
commit to user
2. Dengan kata lain rate yang diterima oleh webserver adalah rate request yang diperoleh loadbalancer dibagi 2. Oleh sebab ituketikan rate pada loadbalancer sebesar 700 req/s web server baru mulai kualahan yang dibuktikan dengan load CPU yang digunakan sebesar 100%.
Pada subbab ini dapat disimpulkan bahwa resource yang dimiliki dapat mempengaruhi performa server. Semakin besar resource yang dimiliki maka semakin besarpula performa yang dihasilkan. Untuk webserver dan load balancer tidahk terlalu membutuhkan resource memory yang besar tetapi tergantung pada resource CPU yang dimiliki
4.4.6 Failover
Failover bertujuan agar saat suatu system mengalami down maka system
yang dijadikan sebagai backup dapat segera menggantikan posisi master yang
down tadi dengan cepat. Pengujian yang dilakukan dengan menggunakan
Topologi 6. Sistem failover pada penelitian ini terletak pada loadbalancer, ada 2 loadbalancer yang ada didalam system ini yaitu loadbalancer lb01 dan lb02 dengan master pada lb01 dan slave pada lb2.
Dalam pengujianya penulis melakukan percobaan dengan membuat
down salah satu server yaitu lb01 dan menganalisa apakah server lb02 dapat
menggantikan fungsi master yang ada pada lb01 sebelumnya dan menganalisa bagaimana jika server lb01 up kembali apakah bisa langsung menjadi master kembali. Untuk mengeceknya dengan cara melakukan ping ke ip virtual yang dimiliki keduanya dan juga dengan melihat status yang interface pada server dengan perintah ifconfig. Disitu nanti bisa melihat sebagai apakah server tersebut berfungsi.
Percobaan yang dilakukan adalah Mematikan server lb01 dengancara mematikan interfacenya. Pengujian dengan menjalankan ping dengan tujuan ip virtual yang ada di kedua server yaitu 10.10.20.100. Sebelum percobaan dimulai cek status pada interface
commit to user
Status loadbalancer lb01 awal
Status loadbalancer lb02 awal
Gambar 4.35 dan gambar 4.36 menunjukkan status sebelum dilakukan percobaan. Dimana lb01 sebagai master dan lb02 sebagai backup dengan ip virtual 10.10.20.100.
Kemudian dilakukan ping sambil mematikan interface lb01 dengan perintah ifconfig em0 down
commit to user
Status loadbalancer lb01 setelah loadbalancer lb01 down
Status loadbalancer lb02 setelah loadbalancer lb01 down Pada gambar 4.38 menunjukkan status yang semula master menjadi INIT artiniya mati karena physical interfacenya down, sebangkan pada lb02 yang semula berstatus sebagai backup setelah lb01 mati maka status lb02 menjadi
master untuk menggantikan lb01 seperti pada gambar 4.39. Padasaat
perpindahan terjadi down sesaat pasa ip virtualnya seperti yang terlihat pada gambar 4.37 yang terjadi request time out satukali pada proses ping. Dengan itu berarti failover berfungsi seperti yang di rencanakan.
Setelah melakukan percobaan pemutusan kemudin dilakukan percobaan lagi dengan menghidupkan lagi lb01 yang di matikan pada percobaan sebelumnya dengan menggunakan perintah ifconfig em0 up
commit to user
Stat us loadbalancer lb01 setelah loadbalancer lb01 up
Status loadbalancer lb02 setelah loadbalancer lb01 up Pada percobaan ini pada saat lb 01 kembali up ip virtual yang semula berada pada lb02 secara langsung akan pindah kembali ke I lb01 kembali tanpa ada delay seperti yang terlihat pada gambar 4.40.
4.4.7 Redundansi database
Pada redundansi database dituntut untuk mempunyai lebih dari 1
database yang dapat di akses. Topologi yang digunakan adalah topologi 6.
Dalam penelitian ini penulis menggunakan 2 node atau databases. Di kedua node tersebut dapat digunakan bersamasama atau loadbalance atau bisa juga dengan bergantian failover. Pada penelitian kaliini penulis menggunakan kedua node tersebut secara bergantian atau failover. Dengan prinsip sama dengan failover pada load balancing server pada subbab sebelumnya jika salah satu database mati maka akan pindah ke database yang lainya tntusaja dipastikan bahwa data antar kedua database itu sama. Dalam penelitian ini penulis memneri hostname pada kedua database itu sebagi db02.netmon.local dan db03.netmon.local sedangkan db01.netmon.local bertindak sebagai server file sharing.
commit to user
Pengunjian yang dilakukan dengan mematikan salah satu database dan kemudian apakah bisa langsung pindah ke node yang lainya. Kemudian jika saat salah satu node mati dan node yang lainya masih melakukan transaksi data baik penambahan atau pengurangan data, akankah node yang mati tadi ketika menyala kembali bisa melakukan sinkronisasi data pada node yang menyala.
Pengujian dilakukan dengan cara mematikan interface pada salahsatu node yaitu db02 dan apakah db03 dapat menggantikan peran db02. Di kedua
database ini terdapat ip yang dimiliki keduanya dan itu dijadikan sebagai alamat database untuk aplikasi web.
Status database db02 sebelum down
Status database db03 sebelum database db02 down
Konsep redudansi database pada penelitian ini menggunakan 2 metode yaitu carp interface sebagi failover dan mysql replikasi sebagai pensinkron data. Dimana replikasi dilakukan 2 arah, db02 mereplikasi db03 dan db03 mereplikasi db02. Prinsip kerjanya jika db02 sebagai master maka db02 akan mengirim kopian query kepada db03 dan jika db03 sebagai master maka akan mengirimkan kopian querynya ke db02. Mysql replikasi adalah salah satu fiture yang ada pada mysql database konfigurasi yang dibutuhkan adalah mengaktivekan log-bin dan memberikan server id yang berbeda pada setiap server database. Konfigurasi
commit to user
selanjutnya adalah membuat user yang digunakan untuk replikasi dengan privilege replication. Server database yang bertindah sebagai slave dikonfigurasi mengikuti log-bin pada master.
Perbandingan data sebelum database db02 down
Pada gambar 4.45 menunjukkan data yang berada pada kedua server sama sebelum salah satu database dimatikan. Kemudian dilakukan percobaab dengan mematikan salah satu database degan cara menonaktifkan interfacenya seperti yang dilakukan saat melakukan percobaan failover. Setelah salah satu
database mati kemudian lakukan input data ke database yang masih menyala.
Saat salah satu database mati maka secara otomatis database yang lainya akan langsung menggantikan posisi master seperti failover pada loadbalancer.
commit to user
input data saat database db02 down
Kemudian setelah itu diaktifkan kembali db02 yang down tadi dengan mengaaktifkan kembali interfacenya. Setelah aktif lihat pada status interface di kedua database.
Status database db02 stelah database db02 up
commit to user
Pada gambar diatas menunjukan saat db02 kembali up db03 tetap sebagai
master hal ini diakrenakan pada db02 yang mempunyai nilai advskew 0
diberikan demotion pada carp interface sebanyak 100 agar nilai keduanya sama. Jadi master akan berpindah jika master itu mati jika dan jika master tersebut tidak mati maka status master tidak akan berpindahhal ini berfungsi untuk memberikan waktu agar database yang mati tadi bisa bisa melakukan sinkronisasi data sebelum dia diakses langsung oleh webserver.
Perintah untuk menurunkan prioritas sebagai master yaitu
Perintah penurunan nilai demotion Yang hasilnya dapat dilihat dengan perintah sysctl net.inet.carp
Status carp database db02
Status carp database db03
commit to user
Perbandingan data setelah database db02 up kembali
Secara default nilai dari demotion adalah 0. Dengan konfigurasi tersebut dapat dikatakan keduanya sebagai master karena memiliki proiritas yang sama tergantung server mana yang up terlebih dahulu maka dia akan menjadi master. Pada gambar 4.53 menunjukkan perbandingan data setelah db02 kembali up. Saat db02 up maka secara otomatis akan membaca log-bin db03 dan mulai melakukan sinkronisasi data.
4.4.8 Keseluruhan sistem
Pada pengujian keseluruhan system yang dilakukan adalah hampirsama dengan pengujian pengujian yang sudah dilakukan pada subbab sebelumnya. Pada pengujian kaliini penulis sudah menggunakan domain untuk pengaksesan
webserver dimana semua system yang dibuat ini ip yang dapat diakses oleh
semua orang adalah ip 10.10.20.100 yaitu ip virtual dari loadbalancer ip tersebut yang dimasukkan ke DNS dan di berikan domain netmon.local doman netmon.local adalah alamat website yang di akses oleh semua orang.
Alur ketika ada seseorang yang melakukan request ke website adalah pertama mereka melakukan request terhadap domain netmon.local melalui web browser dengan bantuan DNS domain netmon.local diterjemahkan kedalam sebuah ip yaitu ip 10.10.20.100 ip tersebeut merupakan ip virtual yang ada pada
loadbalancer, selanjutnya loadbalancer yang bertindak sebagai master dari ip
10.10.20.100 akan meneruskan request yang diberikan oleh pengunjung ke dalam server farm dalam hal ini server farm berisikan 2 buah webserver yaitu
commit to user
web01 dan web02 mengan menggunakan sebuah algoritma load balancer
membagi reques yang datang kemudian server farm yang telah ditunjuk untuk menangani request yang diberikan locadbalancer merespon dengan menyediakan halaman yang diinginkan oleh pengunjung yang diambilkan dari
database dimana database yang bertindak sebagain master yang akan merespon
permintaan webserver setelah mendapatkan respon dari database kemudian
webserver menjawab permintaan pengunjung dalam bentuk html yang kemudian
dapat dibaca oleh web browser.
Ada beberapa algoritma yang bisa dilakukan oleh loadbalancer dalam halini Haproxy. Dalam Haproxy algoritma yang dapat digunakan yaitu round
robin, static round robin, least connection, source, URI, dan URL Parameter. Loadbalancer merupakan salah satu yang dapat mendukung High Availability karena dengan adanya load balancer ketika salah satu web server down maka rekuest yang harusnya ditangani webserver tersebut akan di alihkan
ke server farm yang lainya, dan ketika server tersebut up kembali maka
loadbalancer secara otomatis akan memberikan beban seperti yang sebelumnya.
Jika ingin menambahkan webserver yang baru tinggal dimasukkan kedalam list backend di file konfigurasi haproxy maka setelah direstart service haproxy otomatis langsung menjadi anggota server farm. Load balancer bertugas membagi request ke dalam server farm bagaimana jika loadbalancer servernya mati? Dari situ maka digunakan metode failover di mana dibuat 2 load balancer dengan konfigurasi yang sama yang nantinya salah satu akan menjadi backup ketika salah satunya mati.
Sekarang jarang sekali website yang menggunakan web static. Hampir semua website sekarang ini menggunakan database untuk mengimpan data – data website oleh karena itu databases server merupaka salahsatu komponen penting yang ada pada system ini. Untuk menunjang High Availability database harus mempunyai backup cadangan yang digunakan untuk menggantikan
databases yang asli bila terjadi masalah. Sudah pasti kalau database yang paling
penting adalah data yang ada didalamnya. Sebagai database backup dituntut untuk mempunyai isi data yang sama persis dengan databases yang
commit to user
sesungguhnya. High Availability menuntut database agar saat databases utama fail atau gagal maka secara otomatis akan berpindah menuju database backup tampa merubah suatu konfigurasi apapun pada sisi clientnya dalam hal ini
webserver. Untuk membuat system tersebut ada banyak cara untuk
mengimplementasikannya salah satunya dengan menggunakan ip virtual pada beberapa database sebagai frontendnya kemudian antar database melakukan syncronisasi data dalam penelitian ini menggunakan mysql replication sebagai penyinkron database.
Dari pengujian performa yang dilakukake seluruh system menggunakan parameter Troughput didapatkan data sebagai berikut:
Hasil Uji Parameter Throughput keseluruhan sistem rate
Req/sec
Rata-rata Troughput/req
Topologi 4 Topologi 5 Topologi 6
200 0.779 0.787 0.956 400 0.666 0.677 0.826 700 0.553 0.553 0.663 1000 0.467 0.467 0.570 1500 0.374 0.375 0.461 2000 0.256 0.269 0.385 2500 0.189 0.201 0.329 3000 0.150 0.164 0.286 Rata-rata 0.429 0.436 0.560
Berdasarkan data dari Tabel 4.7 dapat dibuat grafik sebagai berikut
Grafik Perbandingan throughput keseluruhan sistem 0.000 0.200 0.400 0.600 0.800 1.000 1.200 200 400 700 1000 1500 2000 2500 3000
Troughput
Topologi 4 Topologi 5 Topologi 6
RateRequest (req/s) Tro u gh p u t( KB/ s )
commit to user
Dari data tersebut kecenderungan troughput terhadap rate request adalah semakin tinggi rate request yang diberikan maka semakin kecil troughput yang dihasilkan. Peningkatan Throughput dari 1 server menjadi dua server adalah adalah sebesar 30 % di bandingkan dengan percobaan pada subbab sebelumya pertambahan troughput di keseluruhan system lebih kecil, karena di seluruh system ini sudah termasuk troughput database juga jadi koneksi dari ke
webserver sangat mempengarusi troughput keseluruhan system.
Pengujian performa keseluruhan system menggunakan parameter Responstime dadapatkan data sebagai berikut:
Hasil Uji Parameter Response Time keseluruhan sistem rate
Req/sec
Rata-rata Response Time/req Topologi 4 Topologi 5 Topologi 6
200 0.332 0.349 0.741 400 0.151 0.159 0.325 700 0.085 0.084 0.172 1000 0.057 0.059 0.116 1500 0.051 0.060 0.081 2000 0.155 0.126 0.064 2500 0.140 0.124 0.058 3000 0.132 0.116 0.061 Rata-rata 0.138 0.135 0.202
Dati data pada yang dihasilkan pada parameter response time seperti pad table 4.8, maka dapat dibuat grafik sebagai berikut
Grafik Perbandingan response time keseluruhan sistem 0.000 0.200 0.400 0.600 0.800 200 400 700 1000 1500 2000 2500 3000
Response Time
Topologi 4 Topologi 5 Topologi 6
Rate Request (req/s)
Respo n se Tim e( m s)
commit to user
Pada parameter resposntime semakin kecil response time suatu system maka semakin bagus performa system tersebu. Dari hasil pengambilan data pada percobaan ini didapatkan semakin besar rate yang diberikan maka semakin cepat pula responstime yang diberikan. Hal itu terjadi karena semakin besar rate
request yang diberikan maka semakin sedikit request yang dapat dijawab oleh
system tersebut.
Pengujian performa yang ketiga adalah dengan menggunakan parameter
reply sukses data yang didapatkan adalah sebagai berikut:
Hasil Uji Parameter Response Time keseluruhan sistem rate
Req/sec
Reply sukses (req)
Topologi 4 Topologi 5 Topologi 6
200 105.33 110.67 230.00 400 93.00 100.00 214.00 700 92.67 92.67 191.33 1000 87.33 87.33 194.00 1500 86.67 90.67 195.00 2000 91.67 93.00 196.67 2500 94.00 96.00 195.00 3000 93.00 97.33 194.67 Rata-rata 92.96 95.96 201.33
Berdasarkan data pada table 4.9 dapat diperoleh grafik sebagai berikut:
Grafik Perbandingan throughput keseluruhan sistem
Diliahat dari grafik dari pada gambar 4.56 peningkatan jumlah reply sukses yang di hasilkan mencapai 100% hal ini dikarenakan maksimal conection yang diperbolehkan adalah sebesar 100. Jadi jika yang digunakan pada load
0.00 50.00 100.00 150.00 200.00 250.00 200 400 700 1000 1500 2000 2500 3000
Reply sukses
Topologi 4 Topologi 5 Topologi 6
Re
ply
commit to user
balancer 2 server makaa maksimal yang dapat di terima database adalah 200. Peningkatan reply sukses pada percobaan ini bisa dampai 2 kali lipat karena angka maksimal request yang dapat ditangani oleh database masih lebih kecil dibandingkan dengan request yang dapat di tangani oleh web server. Jadi pada percobaan ini keberhasilan reply yang dapat diberikan kepada pengakses tergantung pada performa dari database
