Post on 04-Feb-2021
1
1. Pendahuluan
Perkembangan teknologi semakin memberi kemudahan kepada setiap
orang untuk mengakses data-data yang tersebar di internet. Perkembangan ini
memberikan dampak yang besar terhadap MySQL Server karena beban yang
diterima semakin meningkat. Telah diketahui bahwa penyebab dari akses yang
meningkat ini karena terlalu banyak koneksi ke dalam database, pemrosesan
query yang tidak diperlukan, dan HTTP request yang tidak diperlukan. Seperti
jika pada sebuah database terdapat 1000 user dan semua user melakukan koneksi
secara bersamaan, untuk masing-masing user melakukan 5 query, sehingga
menghasilkan 5000 query yang berlangsung dalam sekali waktu. Untuk MySQL
Server dengan spesifikasi terbatas maka hal ini dapat menyebabkan MySQL
Server mengalami kelebihan beban[1].
Kota Semarang merupakan ibukota propinsi Jawa Tengah dimana
memiliki ratusan ribu warga di dalamnya. Selain jumlah penduduk yang padat,
sekolah juga dibangun dibanyak tempat. Masalah timbul pada saat sebuah
keluarga ingin menyekolahkan anaknya. Mereka akan mencari informasi lengkap
mengenai sekolah yang ingin dimasuki. Tetapi pada kenyataannya masyarakat
tidak mengetahui cara mencari informasi setiap sekolah yang ada sehingga
mereka hanya mengandalkan apa kata orang tentang informasi sekolah yang ada.
Untuk itulah sistem informasi sekolah berbasis online sangat dibutuhkan untuk
membantu keluarga calon siswa dalam mencari sekolah yang cocok untuk anak
mereka. Pada sistem informasi sekolah wilayah Kabupaten Semarang, database
akan diakses secara umum oleh warga Semarang, dan kemungkinan beberapa dari
daerah lainnya. Database dengan jumlah data lebih dari 15000 akan diakses oleh
ratusan ribu orang, dan mencapai puncaknya pada setiap masa kelulusan sekolah.
Ada beberapa macam cara untuk mengatasi hal tersebut. Salah satunya
adalah dengan cara membangun Load Balanced Cluster pada MySQL Server
sehingga beban request yang diterima oleh server dapat dibagikan kepada seluruh
jumlah node yang aktif. Penggunaan Load Balanced Cluster memberikan
keuntungan dimana PC yang digunakan sebagai node tidak menuntut spesifikasi
yang tinggi, sehingga PC dengan spesifikasi rendah juga dapat dipakai. Dengan
adanya node tambahan pada MySQL Server maka kinerja server dapat lebih
dioptimalkan.
Jika cara tersebut dapat diaplikasikan pada MySQL Server untuk
menanggulangi masalah yang ada, pertanyaannya adalah bagaimana cara
membangun Load Balanced MySQL Server Cluster ? Selain itu, berapa besarkah
peningkatan kinerja setelah penambahan node ? Jika sudah terlihat berapa besar
peningkatan kinerja setelah penambahan node, pada node keberapakah dianggap
terbaik untuk menangani MySQL Server ?
2. Tinjauan Pustaka
Mengacu pada penelitian terdahulu yang berupa “Analisis Perbandingan
Algoritma Penjadwalan Load balancer Terhadap Kinerja Web Server Cluster”,
telah menganalisis dengan membandingkan algoritma yang dipakai pada sistem
2
komputasi load balancing cluster, bahwa algoritma penjadwalan menggunakan
least connection memiliki hasil yang lebih baik dari pada round robin. Pada
penelitian tersebut telah dibandingkan berdasarkan connection, time response,
throughput, request lost, dan test duration[2].
Mengacu juga pada penelitian terdahulu yang berupa “Implementasi dan
Evaluasi Kinerja Load Balancing Pada Server-Server Proxy di IPB”, telah
menganalisis bahwa 2 buah server proxy yang dipakai di IPB menjadi lebih baik
jika metode load balance pembobotan yang dipakai adalah 1:2, karena
menghasilkan standard deviasi penggunaan CPU yang paling kecil. Pada
penelitian tersebut telah dibandingkan berdasarkan penggunaan CPU, penggunaan
Memory, Throughput, Total Connection, dan Hit Ratio[3].
Mengacu pada penelitian terdahulu yang berjudul “Perancangan Sistem
Informasi Sekolah Menggunakan Vaadin dengan Pemanfaatan Google Maps di
Kota Semarang”, bahwa masalah yang dihadapi adalah cara pembangunan sistem
informasi berbasis online menggunakan Vaadin. Pada Penelitian ini dilakukan
pembuatan sistem aplikasi berbasis web dengan database menggunakan Postgres
dan penyimpanan data dilakukan secara online, diakses untuk masyarakat
umum[4]. Database sekolah pada penelitian tersebut akan digunakan untuk
penelitian ini.
Dengan adanya sistem load balance, beban kerja yang diterima oleh server
dapat dibagi sesuai jumlah node yang aktif. Dan sistem ini dapat juga diterapkan
untuk database server, sehingga beban akses basis data juga dapat dibagikan
dengan database server yang lain. Pada penelitian ini akan dilakukan perancangan
dan implementasi sistem Load Balanced MySQL Server Cluster, kemudian
membandingkan kinerja load balanced MySQL Server cluster dengan jumlah
node yang berbeda, dan setelah itu akan ditentukan jumlah node yang dapat
dipakai untuk menghasilkan kinerja layanan yang optimal setelah menambah
jumlah node dengan didasarkan pada perbandingan CPU Usage, Memory Usage,
Total Execution Time, Average Execution Time, serta 95% percentile Execution
Time. CPU Usage dan Memory Usage dipakai sebagai parameter karena beban
kerja sebuah node tidak lepas terhadap pemakaian hardware-nya. CPU digunakan
oleh PC sebagai pusat pemrosesan data, sedangkan Memory digunakan oleh PC
sebagai penyimpanan data hasil pemrosesan[5]. Total Execution Time, Average
Execution Time, dan 95% Percentile Execution Time dipakai sebagai parameter
karena waktu pemrosesan merupakan hasil akhir dari keseluruhan kinerja selama
proses berlangsung[6].
3. Metode dan Perancangan Sistem
Metode yang dipakai pada penelitian ini menggunakan PPDIOO yang
merupakan metode Cisco untuk menggambarkan aliran berkelanjutan dari layanan
yang dibutuhkan jaringan. PPDIOO adalah singkatan dari prepare, plan, design,
implement, operate, optimize. Prepare merupakan tahap penentuan arsitektur
jaringan dan kebutuhan sistem. Plan merupakan tahap penentuan kebutuhan
jaringan berdasarkan tujuan, fasilitas, kebutuhan user, dan lainnya. Design
merupakan tahap yang lebih detail dari tahap Plan. Implement merupakan tahap
3
dimana jaringan dibangun berdasarkan tahap Design. Operate merupakan
pengujian akhir dari tahap Implement yang akan mendeteksi kesalahan, koreksi
dan memonitor performa, sekaligus memberikan data awal untuk tahap Optimize.
Optimize merupakan tahap respon dari data yang didapatkan dari tahap Operate,
yang bisa berupa optimalisasi sistem maupun jaringan bahkan sampai merombak
sistem maupun jaringan awalnya jika tidak sesuai dengan harapan. Gambar 1
menunjukkan bagan metode PPDIOO.
Gambar 1 Metode PPDIOO.
Kelebihan dari metode ini adalah: Mengurangi biaya total dari
kepemilikan jaringan; Meningkatkan ketersediaan jaringan; Mengembangkan
percepatan bisnis; Percepatan akses pada aplikasi dan layanan[7]. Pada penelitian
ini, metode PPDIOO sangat cocok karena akan dilakukan pengukuran kinerja
secara total dalam sekali waktu sehingga tidak perlu melakukan proses fase
sebelumnya, dan penggunaan metode ini dapat digunakan secara berlanjut sesuai
dengan perkembangan sistem yang terjadi di masa depan.
Penelitian yang dilakukan menggunakan beberapa node untuk disiapkan
sebagai MySQL Server. Node merupakan bagian dari server yang menjalankan
sistem operasinya sendiri dan bekerja sama dengan node yang lain untuk
menangani suatu request dari client. Pada node yang telah disiapkan kemudian
dilakukan pengukuran kinerja, dengan melakukan akses melalui client yang
melewati bagian Load Balancer. Load Balancer merupakan sebuah bagian dari
server yang diletakkan sebagai penghubung antara client dengan MySQL Server,
dengan fungsi untuk membagikan beban request yang diterima kepada seluruh
node yang aktif. Node yang aktif diberi nama ds1, ds2, ds3, dan ds4. Sinkronisasi
data yang terjadi pada MySQL Server dilakukan dengan menggunakan
Replication. Replication atau replikasi merupakan sistem sinkronisasi yang
terintegrasi di MySQL Server yang terdiri dari Master dan Slave. Master
merupakan acuan database yang akan direplikasi oleh Slave. Sedangkan Slave
merupakan node yang akan melakukan replikasi sesuai dengan perubahan data
pada Master.
Untuk tahap Prepare, arsitektur pada sistem yang dibuat adalah sistem
yang menghubungkan client dan server dengan melewati sebuah node yang
berfungsi sebagai load balancer. Kebutuhan software pada jaringan adalah Sistem
Operasi, Load Balancer, MySQL server, SSH client. Pengukuran dilakukan
dalam 3 tahap, tahap untuk mengukur kinerja server dengan 2 node, dengan 3
node, dan 4 node. Database yang akan digunakan untuk pengukuran adalah data
informasi seluruh Sekolah Kabupaten Semarang.
Untuk tahap Plan, kebutuhan sistem adalah software pengukuran kinerja
yang akan diletakkan pada client, dan sistem replikasi pada MySQL server.
Prepare Plan Design
Implement Operate Optimize
4
Untuk tahap Design, software yang akan dipakai adalah HAProxy sebagai
Load Balancer, Debian sebagai sistem operasi, Sysbench sebagai software
pengukuran kinerja. Arsitektur jaringan disesuaikan dengan kebutuhan sistem
pada masing-masing pengukuran.
Gambar 2 Skema Replikasi 2 Node.
Gambar 2 menunjukkan skema replikasi untuk pengukuran 2 node.
Masing-masing node mereplikasi database satu sama lain. Master dari ds1 adalah
ds2, master dari ds2 adalah ds1.
Gambar 3 Skema Replikasi 3 Node.
Gambar 3 menunjukkan skema replikasi untuk pengukuran 3 node.
Masing-masing node mereplikasi database sesuai dengan master acuannya.
Master dari ds1 adalah ds2, master dari ds2 adalah ds3, master dari ds3 adalah
ds1.
Gambar 4 Skema Replikasi 4 Node.
Gambar 4 menunjukkan skema replikasi untuk pengukuran 4 node.
Masing-masing node mereplikasi database sesuai dengan master acuannya.
Master dari ds1 adalah ds2, master dari ds2 adalah ds3, master dari ds3 adalah
ds4, master dari ds4 adalah ds1.
Untuk tahap Implement, sistem dibagi menjadi 3 bagian, yaitu : client,
front-end, dan back-end. Client dibangun secara virtual dengan spesifikasi
prosesor Intel i5 1.7GHz, 512MB RAM, 8GB harddisk. Front-end yang berfungsi
sebagai Load Balancer dibangun secara virtual dengan spesifikasi prosesor Intel
i5 1.7GHz, 512MB RAM, 8GB harddisk. Back-end yang berfungsi sebagai
database server dibangun secara fisik dengan spesifikasi prosesor Intel Pentium
IV 3.0GHz, 512MB RAM, dan 40GB harddisk. Software yang diletakkan pada
client adalah sistem operasi Debian, SSH client, dan Sysbench. Software yang
diletakkan pada front-end adalah sistem operasi Debian, SSH client, Samba
Client, dan HAProxy. Software yang diletakkan pada back-end adalah sistem
ds1
ds2
ds4 ds3
ds1
ds2 ds3
ds1 ds2
5
operasi Debian, SSH client, Samba Client, dan MySQL server. Gambar 5
menunjukkan arsitektur jaringan Load Balance Cluster.
Gambar 5 Arsitektur Jaringan Load Balance Cluster.
Gambar 5 menunjukkan bahwa arsitektur yang dipakai mengharuskan
client melewati front-end untuk bisa berkomunikasi dengan back-end. Front-end
yang berfungsi sebagai load balancer akan mengarahkan permintaan pada salah
satu node pada bagian back-end. Permintaan diproses dan dikembalikan kepada
front-end, kemudian front-end mengembalikan hasil permintaan pada client yang
melakukan permintaan.
Pada software Sysbench juga dilakukan konfigurasi file untuk
mengaplikasikan sistem load balance mencapai 4 node. Sedangkan pada software
MySQL dilakukan konfigurasi master pada file my.cnf dan konfigurasi slave pada
command line MySQL. Untuk mengaktifkan konfigurasi master pada MySQL
perlu dilakukan restart service MySQL setelah file my.cnf selesai dikonfigurasi.
Konfigurasi slave dilakukan dengan mengacu pada konfigurasi master yang
dipilih. Selain itu perlu dilakukan konfigurasi hak akses replikasi dari node lain
dan hak akses query data dari front-end. Pada masing-masing jumlah node
memiliki konfigurasi master dan slave yang berbeda-beda, sehingga pada setiap
akhir pengukuran, perlu dilakukan konfigurasi ulang master dan slave.
Untuk tahap Operate, dilakukan pengecekan sistem dari client
menggunakan aplikasi Sysbench sehingga dapat diketahui apakah sistem telah
bekerja dengan baik. Jika sistem telah bekerja dengan baik maka kemudian
dilakukan pengukuran kinerja terhadap sistem. Dan setelah pengukuran kinerja
dilakukan pada tiap-tiap jumlah node, maka kemudian dilakukan perbandingan
kinerja dari tiap-tiap jumlah node. Setelah didapatkan perbandingan jumlah
kinerja dari tiap-tiap jumlah node, kemudian akan ditentukan pada node
berapakah kinerja server dianggap optimal.
Proses perbandingan kinerja dilakukan dengan langkah-langkah sebagai
berikut : Pembuatan Grafik Pengukuran Kinerja pada masing-masing jumlah
node; Perhitungan selisih pengukuran kinerja dari 2 node ke 3 node, 3 node ke 4
node, dan 2 node ke 4 node; Perhitungan persentase selisih pengukuran kinerja
dengan membandingkan dari kinerja 2 node; Perhitungan rata-rata dari masing-
masing parameter; Dan, perhitungan Persentase keseluruhan.
Untuk tahap Optimize, akan ditentukan berdasarkan hasil yang diperoleh
setelah tahap Operate selesai dilakukan.
4. Hasil dan Pembahasan
Sistem dibangun sesuai dengan pada tahap design yang telah dibuat.
Hardware serta software yang dipakai juga sesuai dengan tahap design. Pertama
Back-end
Front
-end
Client
6
hardware disusun sesuai dengan arsitektur pada tahap design. Setelah hardware
selesai dibangun sesuai arsitektur jaringan, kemudian dilakukan konfigurasi pada
software. Sistem dibangun dengan sistem operasi Debian. Software yang dipakai
berbeda satu sama lain sesuai dengan bagian sistemnya masing-masing. Sistem
yang dibangun memiliki 3 bagian : back-end, front-end, dan client.
Pembangunan pada sisi back-end, dilakukan secara bertahap. Konfigurasi
dilakukan dengan merubah isi dari file/etc/mysql/my.cnf yang melibatkan beberapa
bagian, serta memberikan hak akses replikasi dari node lain, hak akses manipulasi
data dari Front-End, dan konfigurasi Master-Slave.
Konfigurasi file pada bagian Fine Tuning tidak dirubah dan masih
menggunakan konfigurasi secara default. Konfigurasi file pada bagian Replication
dirubah dengan memperhatikan bagian server-id dan auto_increment_offset,
bahwa isi pada tiap node tidaklah sama. Untuk ds1 menggunakan nominal 1,
untuk ds2 menggunakan nominal 2, untuk ds3 menggunakan nominal 3, untuk ds4
menggunakan nominal 4. Gambar 6 menunjukkan Konfigurasi Replication yang
diatur pada node ds1.
Gambar 6 Konfigurasi Replication pada file my.cnf.
Pada Gambar 6, baris server-id merupakan id dari node tersebut. Baris
log_bin merupakan file untuk menyimpan log dari perubahan yang dilakukan oleh
node tersebut. Baris expire_logs_days merupakan lama hari yang ditetapkan untuk
menentukan waktu kadaluarsa baris log yang tersimpan. Baris max_binlog_size
merupakan batas maksimal ukuran jumlah baris log. Baris binlog_do_db
merupakan database yang akan diakses pada replikasi. Baris binlog_ignore_db
merupakan database yang tidak akan diakses pada replikasi. Baris auto-
increment-offset merupakan penentuan id awal untuk setiap baris database yang
ditambahkan ke dalam database. Baris auto-increment-increment merupakan
penentuan peningkatan nomor id pada setiap baris yang ditambahkan ke dalam
database. Baris log-slave-updates merupakan perintah slave untuk melakukan
update log. Baris replicate-same-server-id merupakan perintah untuk mereplikasi
log dengan id server yang sama, isi pada baris ini bertipe boolean.
Pengaktifan konfigurasi MySQL Server yang baru saja dibuat dilakukan
dengan cara restart service mysql. Setelah restart service mysql, kemudian
dilakukan konfigurasi melalui mysql command line. Yang dilakukan pertama kali
melalui mysql command line adalah memberikan hak akses manipulasi data dari
front-end / load balancer. Pemberian hak akses untuk replikasi juga diberikan
untuk masing-masing node.
Konfigurasi terakhir untuk back-end dilakukan melalui mysql command
line. Pada pembangunan cluster 2 node, ds1 akan ditetapkan sebagai master dari
7
ds2, dan ds2 akan ditetapkan sebagai master dari ds1. Pada pembangunan cluster
3 node, ds1 ditetapkan sebagai master dari ds2, ds2 ditetapkan sebagai master dari
ds3, dan ds3 ditetapkan sebagai master dari ds1. Pada pembangunan cluster 4
node, ds1 ditetapkan sebagai master dari ds2, ds2 ditetapkan sebagai master dari
ds3, ds3 akan ditetapkan sebagai master dari ds4, dan ds4 akan ditetapkan sebagai
master dari ds1. Untuk konfigurasi sebagai slave, sebuah node membutuhkan data
master dari node lain yang ditetapkan sebagai master dari node tersebut.
Pembangunan cluster dengan jumlah node yang berbeda dilakukan
bertahap, karena akan dilakukan pengukuran setelah cluster berhasil dibangun.
Untuk pertama dibangun cluster 2 node terlebih dahulu, kemudian diukur.
Kemudian akan dibangun cluster 3 node yang selanjutnya akan diukur lagi dengan
parameter yang sama. Dan terakhir adalah dibangun cluster 4 node dan kemudian
diukur kembali dengan parameter yang sama.
Pembangunan pada sisi front-end, dilakukan secara virtual. Bagian ini
berfungsi sebagai load balancer, yang pada penelitian ini akan menggunakan
HAProxy sebagai aplikasi load balancer. Konfigurasi HAProxy sebagai load
balancer dapat dilihat pada Gambar 7.
Gambar 7 Konfigurasi Load Balancer HAProxy.
Pada Gambar 7, baris global merupakan sebuah bagian yang baris perintah
di dalamnya akan diaplikasikan pada setiap bagian pengaturan. Baris daemon
merupakan perintah untuk menjalankan aplikasi HAProxy secara background.
Baris defaults merupakan sebuah bagian yang baris perintah di dalamnya akan
diaplikasikan secara default. Baris mode merupakan perintah kepada HAProxy
untuk membaca data yang lewat pada protokol tcp. Baris option merupakan
perintah load balance yang dilakukan. Baris retries merupakan jumlah koneksi
ulang yang dilakukan jika terjadi kegagalan koneksi. Baris maxconn merupakan
jumlah koneksi maksimal yang ditetapkan untuk ditangani. Baris timeout connect
merupakan lama waktu yang ditentukan untuk koneksi. Baris timeout client
merupakan lama waktu yang ditentukan untuk tersambung dengan client. Baris
timeout server merupakan lama waktu yang ditentukan untuk tersambung dengan
8
server. Baris frontend mysql_load_balancer merupakan bagian pengaturan yang
baris-baris di dalamnya akan diaplikasikan pada load balancer dengan nama
mysql_load_balancer. Baris bind merupakan perintah kepada HAProxy untuk
melakukan penguncian koneksi pada ip dan port yang ditetapkan. Baris
default_backend merupakan nama backend yang ditetapkan sebagai default pada
setiap request yang diterima. Baris backend mysqlserver merupakan bagian
pengaturan yang baris di dalamnya akan diaplikasikan pada backend server,
dengan nama mysqlserver. Baris balance merupakan jenis algoritma load balance
yang dipakai pada load balancer. Baris server merupakan baris node yang dipakai
untuk MySQL Server dengan nama masing-masing dan IP serta port yang
digunakan pada masing-masing node, perintah check pada baris server
merupakan perintah untuk melakukan pengecekan apakah node tersebut sedang
aktif atau tidak. Baris listen merupakan bagian pada pengaturan untuk web-
interface HAProxy. Baris mode merupakan penentuan mode untuk menjalankan
web-interface. Baris bind merupakan perintah untuk mengikat koneksi yang
terkoneksi pada IP load balancer pada port yang ditentukan. Baris stats
merupakan penentuan aktifasi web interface.
Pembangunan pada sisi client, dilakukan secara virtual. Bagian ini
berfungsi sebagai media pengukuran. Aplikasi yang digunakan adalah Sysbench.
Pengujian replikasi dilakukan langsung pada bagian back-end untuk
mendapatkan hasil yang pasti. Yang pertama dilakukan adalah membuat database
datasekolah pada salah satu node. Kemudian dilakukan cek apakah pada node lain
telah memiliki database dengan nama datasekolah. Pengecekan dilakukan melalui
command line Debian. Pengujian load balancer dilakukan melalui client. Client
akan mengakses MySQL yang ada pada back-end melalui load balancer.
Load Balancer yang bertindak sebagai load balancer akan meneruskan
permintaan dari client ke salah satu node yang aktif. Pengecekan dilakukan
dengan melihat langsung melalui web interface yang disediakan oleh load
balancer. Gambar 8 menunjukkan tampilan web-interface HAProxy saat
meneruskan koneksi MySQL ke setiap node yang ada.
Gambar 8 Tampilan web interface load balancer HAProxy.
Pada Gambar 8, terlihat 3 tabel dengan nama mysql_load_balancer,
mysqlserver, dan admin. Semua tabel tersebut merupakan hasil dari konfigurasi
seperti terlihat pada Gambar 7. Kolom Queue merupakan kolom untuk melihat
antrean koneksi, kolom Cur merupakan jumlah antrean koneksi yang terhubung
9
yang sedang berlangsung, kolom Max merupakan jumlah maksimal antrean
koneksi yang terhubung, kolom Limit merupakan batas antrean koneksi yang
ditentukan. Kolom Session rate merupakan rata-rata Session yang terjadi selama 5
detik, kolom Cur merupakan jumlah rata-rata koneksi yang terikat yang sedang
berlangsung, kolom Max merupakan jumlah maksimal rata-rata session yang
terhubung, kolom Limit merupakan batasan maksimal rata-rata session yang
ditentukan. Kolom Sessions merupakan jumlah Session yang terikat pada
HAProxy, kolom Cur merupakan koneksi yang sedang terhubung, kolom Max
merupakan jumlah maksimal session yang terhubung, kolom Limit merupakan
batas maksimal koneksi terhubung yang telah ditentukan, kolom Total merupakan
jumlah koneksi yang terhubung selama HAProxy menyala, kolom LbTot
merupakan jumlah Session yang telah load balance. Kolom Bytes merupakan
jumlah ukuran data selama HAProxy dinyalakan dalam ukuran byte, kolom In
merupakan jumlah ukuran data yang berasal dari client, Out merupakan jumlah
ukuran data yang berasal dari node. Kolom Denied merupakan jumlah koneksi
yang ditolak, Req merupakan jumlah permintaan dari client yang ditolak, Resp
merupakan jumlah tanggapan yang berasal dari node server. Kolom Errors
merupakan jumlah koneksi yang error, kolom Req merupakan jumlah permintaan
dari client yang error, kolom Conn merupakan jumlah koneksi yang mengalami
error, Resp merupakan jumlah tanggapan dari server node yang error. Warnings
merupakan jumlah peringatan dari HAProxy, Retr merupakan jumlah peringatan
karena pengulangan koneksi dari client, Redis merupakan peringatan karena
pengulangan koneksi saat melakukan load balance. Kolom Server merupakan
kolom yang memperlihatkan status server, kolom Status merupakan kolom yang
menunjukkan berapa lama server aktif atau tidak aktif, kolom LastChk merupakan
kolom yang menunjukkan hasil pengecekan yang terakhir yang dilakukan, Wght
merupakan kolom yang menunjukkan berat node untuk variable perhitungan
algoritma penjadwalan dimana nilai yang lebih tinggi merupakan node yang
memiliki tingkat kinerja lebih baik dibanding yang lebih rendah, kolom Act
merupakan kolom yang menunjukkan apakah node tersebut aktif atau tidak,
kolom Bck merupakan kolom yang menunjukkan jumlah node dibelakang node
tersebut, kolom Chk merupakan kolom yang menunjukkan pengecekan node,
kolom Dwn merupakan jumlah server down yang dialami oleh node, kolom
Dwntme merupakan kolom yang menunjukkan berapa lama node mengalami
down, kolom Thrtle merupakan kolom yang menunjukkan pembatasan koneksi
kepada node.
Pengukuran kinerja dengan tahapan : Pengisian database datasekolah pada
setiap node; Penentuan jumlah client yang dapat diterima oleh cluster 2 node;
Persiapan variable dalam pengukuran; Pengukuran kinerja untuk cluster 2 node, 3
node dan 4 node.
Pengisian database dilakukan dengan cara meng-import file database
melalui mysql command line. Penentuan maksimal client yang dapat diterima oleh
cluster 2 node dilakukan dengan SysBench dengan memberikan nilai --num-
threads=100 untuk mengukur MySQL server dengan 100 koneksi secara
bersamaan. Jika hasil pengukuran SysBench mengalami error dengan pesan
terlalu banyak koneksi, maka langkah selanjutnya adalah melihat pada web
10
interface load balancer. Gambar 9 menunjukkan pesan error yang terjadi pada
client SysBench.
Gambar 9 Pesan error unknown database.
Pada Gambar 9, baris pertama menunjukkan pesan tidak dapat terhubung
dengan MySQL Server, baris kedua menunjukkan pesan error yang menjadi
sebab tidak dapat terhubung yaitu terlalu banyak koneksi yang diterima, baris
ketiga menunjukkan pesan gagal terhubung dengan server database, baris
keempat menunjukkan pesan gagal terhubung dengan server database pada thread
nomor 302.
Setelah melihat pesan error pada laporan Sysbench, maka selanjutnya
adalah melihat pada web interface HAProxy. Pada bagian mysqlserver terdapat
beberapa kolom, dan yang diambil adalah nilai kolom Max pada kolom Sessions.
Gambar 10 memperlihatkan nilai maksimal koneksi MySQL pada tiap node yang
aktif.
Gambar 10 Kolom Max pada Kolom Sessions web interface HAProxy.
Pada Gambar 10, kolom Max memperlihatkan jumlah koneksi yang
terhubung berjumlah 28 pada node ds1 dan ds2. Hal ini menunjukkan bahwa
koneksi yang berhasil terhubung adalah 27 sedangkan koneksi terakhir yang
dibuat terjadi error seperti terlihat pada laporan aplikasi Sysbench. Sehingga
variabel jumlah client ditentukan sebanyak 54.
Variable yang disiapkan dalam pengukuran adalah jumlah client, jumlah
node, jumlah transaksi, dan tipe transaksi. Sedangkan parameter yang dicari
adalah %Usage CPU pada masing-masing node, %Usage Memory pada masing-
masing node, Total Execution Time (s), Average Execution Time (ms), dan 95%
Percentile Execution Time (ms). Variable jumlah client merupakan jumlah client
yang melakukan koneksi, jumlah node merupakan jumlah node yang dipakai
dalam pengukuran, jumlah transaksi merupakan jumlah transaksi yang
pengerjaannya akan dibagi kepada masing-masing client, tipe transaksi adalah
jenis transaksi yang dipakai dalam pengukuran apakah Read Only atau Read
Write. Jenis transaksi yang digunakan diaktifkan pada command line Sysbench
dengan perintah --oltp-read-only=on dan --oltp-read-only=off untuk nonaktif.
Jumlah transaksi diaktifkan dengan command line --max-requests=1000 untuk
jumlah transaksi sebanyak 1000. Jumlah transaksi yang akan diukur menggunakan
nilai 1000 sebagai nilai awal pengukuran dengan kenaikan sebesar 1000 tiap
pengukuran sampai 10000 transaksi. %Usage CPU dan %Usage Memory dicatat
11
dengan melihat langsung laporan perintah top pada masing-masing node. Gambar
11 menunjukkan tampilan daftar proses pada node ds1 pada saat MySQL
memproses request dari client.
Gambar 11 Tampilan %Usage CPU dan Memory MySQL.
Ada Gambar 11 menunjukkan hasil perintah top pada proses mysqld yang
merupakan proses MySQL. Pada kolom %CPU menunjukkan beban CPU yang
terpakai, dan kolom %Mem menunjukkan beban Memory yang terpakai. Dari
kedua kolom itu diambil parameter beban CPU dan beban Memory yang terpakai.
Parameter Total Execution Time, Average Execution Time dan 95
percentile Execution Time diambil melalui laporan Sysbench yang keluar setelah
proses selesai dilakukan. Gambar 12 Menunjukkan laporan SysBench.
Gambar 12 Laporan SysBench.
Pada Gambar 12 terlihat laporan hasil pengukuran menggunakan
Sysbench. Pada bagian OLTP test statistics, queries performed merupakan jumlah
query yang telah dilakukan, dimana query read merupakan query dengan perintah
SELECT, query write merupakan query dengan perintah UPDATE, DELETE,
INSERT, dan query other merupakan query dengan perintah selain read dan write,
total merupakan jumlah keseluruhan query read, write dan other. Transactions
merupakan jumlah transaksi yang dilakukan. Deadlocks merupakan error yang
terjadi pada aplikasi Sysbench secara random karena jumlah transaksi yang besar.
Read/write requests merupakan jumlah query read dan write. Other operations
merupakan jumlah query selain read dan write. Pada bagian Test Execution
Summary, total time merupakan waktu keseluruhan untuk menyelesaikan operasi.
Total number of events merupakan jumlah transaksi yang dilakukan. Total time
taken by event execution merupakan jumlah waktu keseluruhan sejak perintah
pada Sysbench diberikan. Per-request statistics merupakan waktu yang
dibutuhkan untuk menyelesaikan 1 request, min merupakan waktu terkecil yang
dilakukan oleh 1 request, avg merupakan waktu rata-rata yang dilakukan oleh 1
request, max merupakan waktu terbesar yang dilakukan oleh 1 request, approx 95
percentile merupakan waktu rata-rata semua request dengan mengeliminasi waktu
12
terbesar sebanyak 5%. Thread fairness merupakan tingkat kewajaran thread,
events (avg/stddev) merupakan hasil dari waktu rata-rata event dibagi standar
deviasi, execution time (avg/stddev) merupakan hasil dari waktu eksekusi rata-rata
dibagi standar deviasi.
Setelah semua parameter disiapkan, kemudian akan dilakukan pengukuran
kinerja. Pengukuran dilakukan pada cluster 2 node, cluster 3 node, dan cluster 4
node, kemudian dilakukan perbandingan pada ketiga cluster yang ada. Gambar 13
menunjukkan perbandingan beban CPU pada ketiga cluster dengan transaksi
berjenis Read Only dari hasil pengukuran.
Gambar 13 Grafik Perbandingan Beban CPU Read Only.
Pada Gambar 13, 2N merupakan beban CPU rata-rata yang dialami oleh
cluster 2 node, 3N merupakan beban CPU rata-rata yang dialami oleh cluster 3
node, 4N merupakan beban CPU rata-rata yang dialami oleh cluster 4 node.
Sesuai dengan konfigurasi pada bagian Fine Tuning yang memberikan alokasi
CPU sebesar 32 sebagai nilai konstan pada masing-masing koneksi yang
terhubung sehingga perhitungan dari beban CPU untuk jenis transaksi Read Only
adalah 32MHz dikalikan dengan jumlah koneksi yang terhubung. Perbedaan pada
masing-masing hasil monitoring dapat ditoleransi karena masih dalam tahap
wajar. Dari grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2
node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih
tersebut dibuat persentase berdasarkan poin pada 2 node. Setelah selisih
didapatkan, pada masing-masing selisih diambil rata-rata dengan menjumlahkan
seluruh persentase pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2
node ke 3 node menghasilkan 37.7024%, dari 3 node ke 4 node menghasilkan
15.1063%, dan dari 2 node ke 4 node menghasilkan 52.8087%.
Gambar 14 menunjukkan perbandingan beban CPU pada ketiga cluster
dengan transaksi berjenis Read Write dari hasil pengukuran.
0
10
20
30
40
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
PER
SEN
TASE
JUMLAH TRANSAKSI
BEBAN CPU READ ONLY
2N 3N 4N
13
Gambar 14 Grafik Perbandingan Beban CPU Read Write.
Pada Gambar 14, 2N merupakan beban CPU rata-rata yang dialami oleh
cluster 2 node, 3N merupakan beban CPU rata-rata yang dialami oleh cluster 3
node, 4N merupakan beban CPU rata-rata yang dialami oleh cluster 4 node.
Sesuai dengan konfigurasi pada bagian Fine Tuning yang memberikan alokasi
CPU sebesar 32 sebagai nilai konstan pada masing-masing koneksi yang
terhubung sehingga perhitungan dari beban CPU untuk jenis transaksi Read Write
adalah 32MHz dikalikan dengan jumlah koneksi yang terhubung dikalikan 2
untuk konstanta jenis transaksi Read Write. Perbedaan pada masing-masing hasil
monitoring dapat ditoleransi karena masih dalam tahap wajar. Dari grafik yang
telah dibuat dapat dihitung poin selisih penggunaan 2 node ke 3 node, 3 node ke 4
node, dan 2 node ke 4 node. Kemudian dari selisih tersebut dibuat persentase
berdasarkan poin pada 2 node. Setelah selisih didapatkan, pada masing-masing
selisih diambil rata-rata dengan menjumlahkan seluruh persentase pada jumlah
transaksi 1000 sampai 10000. Sehingga dari 2 node ke 3 node menghasilkan
36.9833%, dari 3 node ke 4 node menghasilkan 14.7885%, dan dari 2 node ke 4
node menghasilkan 51.7718%.
Gambar 15 menunjukkan perbandingan beban Memory pada ketiga cluster
dengan transaksi berjenis Read Only dari hasil pengukuran.
Gambar 15 Grafik Perbandingan Beban Memory Read Only.
0
20
40
60
80
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
PO
IN
JUMLAH TRANSAKSI
BEBAN CPU READ WRITE
2N 3N 4N
0
5
10
15
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
PO
IN
JUMLAH TRANSAKSI
BEBAN MEMORY READ ONLY
2N 3N 4N
14
Pada Gambar 15, 2N merupakan beban Memory rata-rata yang dialami
oleh cluster 2 node, 3N merupakan beban Memory rata-rata yang dialami oleh
cluster 3 node, 4N merupakan beban Memory rata-rata yang dialami oleh cluster 4
node. Sesuai dengan konfigurasi pada bagian Fine Tuning yang memberikan
alokasi Memory sebesar 2048KB sebagai nilai konstan pada masing-masing
koneksi yang terhubung sehingga perhitungan dari beban Memory untuk jenis
transaksi Read Only adalah 2048KB dikalikan dengan jumlah koneksi yang
terhubung dikalikan 1 untuk konstanta jenis transaksi Read Only. Perbedaan pada
masing-masing hasil monitoring dapat ditoleransi karena masih dalam tahap
wajar. Dari grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2
node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih
tersebut dibuat persentase berdasarkan poin pada 2 node. Setelah selisih
didapatkan, pada masing-masing selisih diambil rata-rata dengan menjumlahkan
seluruh persentase pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2
node ke 3 node menghasilkan 11.6198%, dari 3 node ke 4 node menghasilkan
21.4818%, dan dari 2 node ke 4 node menghasilkan 33.1015%.
Gambar 16 menunjukkan perbandingan beban Memory pada ketiga cluster
dengan transaksi berjenis Read Write dari hasil pengukuran.
Gambar 16 Grafik Perbandingan Beban Memory Read Write.
Pada Gambar 16, 2N merupakan beban Memory rata-rata yang dialami
oleh cluster 2 node, 3N merupakan beban Memory rata-rata yang dialami oleh
cluster 3 node, 4N merupakan beban Memory rata-rata yang dialami oleh cluster 4
node. Sesuai dengan konfigurasi pada bagian Fine Tuning yang memberikan
alokasi Memory sebesar 2048KB sebagai nilai konstan pada masing-masing
koneksi yang terhubung sehingga perhitungan dari beban Memory untuk jenis
transaksi Read Write adalah 2048KB dikalikan dengan jumlah koneksi yang
terhubung dikalikan 1 untuk konstanta jenis transaksi Read Only. Perbedaan pada
masing-masing hasil monitoring dapat ditoleransi karena masih dalam tahap
wajar. Dari grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2
node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih
0
5
10
15
20
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
PO
IN
JUMLAH TRANSAKSI
BEBAN MEMORY READ WRITE
2N 3N 4N
15
tersebut dibuat persentase berdasarkan poin pada 2 node. Setelah selisih
didapatkan, pada masing-masing selisih diambil rata-rata dengan menjumlahkan
seluruh persentase pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2
node ke 3 node menghasilkan -0.8772%, dari 3 node ke 4 node menghasilkan
21.1433%, dan dari 2 node ke 4 node menghasilkan 20.2661%.
Gambar 17 menunjukkan perbandingan Total Execution Time pada ketiga
cluster dengan transaksi berjenis Read Only dari hasil pengukuran.
Gambar 17 Grafik Perbandingan Total Execution Time Read Only.
Pada Gambar 17, 2N merupakan Total Execution Time yang dialami oleh
cluster 2 node, 3N merupakan Total Execution Time yang dialami oleh cluster 3
node, 4N merupakan Total Execution Time yang dialami oleh cluster 4 node. Dari
grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2 node ke 4 node,
3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih tersebut dibuat
persentase berdasarkan poin pada 2 node. Setelah selisih didapatkan, pada
masing-masing selisih diambil rata-rata dengan menjumlahkan seluruh persentase
pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2 node ke 3 node
menghasilkan 18.1827%, dari 3 node ke 4 node menghasilkan -0.1917%, dan dari
2 node ke 4 node menghasilkan 17.9910%.
Gambar 18 menunjukkan perbandingan Total Execution Time pada ketiga
cluster dengan transaksi berjenis Read Write dari hasil pengukuran.
0
10
20
30
40
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
DET
IK
JUMLAH TRANSAKSI
TOTAL EXECUTION TIME READ ONLY
2N 3N 4N
16
Gambar 18 Grafik Perbandingan Total Execution Time Read Write.
Pada Gambar 18, 2N merupakan Total Execution Time yang dialami oleh
cluster 2 node, 3N merupakan Total Execution Time yang dialami oleh cluster 3
node, 4N merupakan Total Execution Time yang dialami oleh cluster 4 node. Dari
grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2 node ke 3 node,
3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih tersebut dibuat
persentase berdasarkan poin pada 2 node. Setelah selisih didapatkan, pada
masing-masing selisih diambil rata-rata dengan menjumlahkan seluruh persentase
pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2 node ke 3 node
menghasilkan 6.1869%, dari 3 node ke 4 node menghasilkan 4.6726%, dan dari 2
node ke 4 node menghasilkan 10.8595%.
Gambar 19 menunjukkan perbandingan Average Execution Time pada
ketiga cluster dengan transaksi berjenis Read Only dari hasil pengukuran.
Gambar 19 Grafik Perbandingan Average Execution Time Read Only.
Pada Gambar 19, 2N merupakan Average Execution Time yang dialami
oleh cluster 2 node, 3N merupakan Average Execution Time yang dialami oleh
0
20
40
60
80
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
DET
IK
JUMLAH TRANSAKSI
TOTAL EXECUTION TIME READ WRITE
2N 3N 4N
0
100
200
300
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
MIL
IDET
IK (
MS)
JUMLAH TRANSAKSI
AVERAGE EXECUTION TIME READ ONLY
2N 3N 4N
17
cluster 3 node, 4N merupakan Average Execution Time yang dialami oleh cluster
4 node. Dari grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2
node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih
tersebut dibuat persentase berdasarkan poin pada 2 node. Setelah selisih
didapatkan, pada masing-masing selisih diambil rata-rata dengan menjumlahkan
seluruh persentase pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2
node ke 3 node menghasilkan 18.7544%, dari 3 node ke 4 node menghasilkan -
0.2184%, dan dari 2 node ke 4 node menghasilkan 18.5360%.
Gambar 20 menunjukkan perbandingan Average Execution Time pada
ketiga cluster dengan transaksi berjenis Read Write dari hasil pengukuran.
Gambar 20 Grafik Perbandingan Average Execution Time Read Write.
Pada Gambar 20, 2N merupakan Average Execution Time yang dialami
oleh cluster 2 node, 3N merupakan Average Execution Time yang dialami oleh
cluster 3 node, 4N merupakan Average Execution Time yang dialami oleh cluster
4 node. Dari grafik yang telah dibuat dapat dihitung poin selisih penggunaan 2
node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node. Kemudian dari selisih
tersebut dibuat persentase berdasarkan poin pada 2 node. Setelah selisih
didapatkan, pada masing-masing selisih diambil rata-rata dengan menjumlahkan
seluruh persentase pada jumlah transaksi 1000 sampai 10000. Sehingga dari 2
node ke 3 node menghasilkan 6.1636%, dari 3 node ke 4 node menghasilkan
4.0505%, dan dari 2 node ke 4 node menghasilkan 10.2141%.
Gambar 21 menunjukkan perbandingan 95 Percentile Execution Time pada
ketiga cluster dengan transaksi berjenis Read Only dari hasil pengukuran.
0
100
200
300
400
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
MIL
IDET
IK (
MS)
JUMLAH TRANSAKSI
AVERAGE EXECUTION TIME READ WRITE
2N 3N 4N
18
Gambar 21 Grafik Perbandingan 95 Percentile Execution Time Read Only.
Pada Gambar 21, 2N merupakan 95 Percentile Execution Time yang
dialami oleh cluster 2 node, 3N merupakan 95 Percentile Execution Time yang
dialami oleh cluster 3 node, 4N merupakan 95 Percentile Execution Time yang
dialami oleh cluster 4 node. Dari grafik yang telah dibuat dapat dihitung poin
selisih penggunaan 2 node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node.
Kemudian dari selisih tersebut dibuat persentase berdasarkan poin pada 2 node.
Setelah selisih didapatkan, pada masing-masing selisih diambil rata-rata dengan
menjumlahkan seluruh persentase pada jumlah transaksi 1000 sampai 10000.
Sehingga dari 2 node ke 3 node menghasilkan 16.9911%, dari 3 node ke 4 node
menghasilkan -0.1866%, dan dari 2 node ke 4 node menghasilkan 16.8046%.
Gambar 22 menunjukkan perbandingan 95 Percentile Execution Time pada
ketiga cluster dengan transaksi berjenis Read Write dari hasil pengukuran.
Gambar 22 Grafik Perbandingan 95 Percentile Execution Time Read Write.
Pada Gambar 22, 2N merupakan 95 Percentile Execution Time yang
dialami oleh cluster 2 node, 3N merupakan 95 Percentile Execution Time yang
0
100
200
300
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
MIL
IDET
IK(M
S)
JUMLAH TRANSAKSI
95 PERCENTILE EXECUTION TIME READ ONLY
2N 3N 4N
0
200
400
600
800
1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 1 0 0 0 0
MIL
IDET
IK (
MS)
JUMLAH TRANSAKSI
95 PERCENTILE EXECUTION TIME READ WRITE
2N 3N 4N
19
dialami oleh cluster 3 node, 4N merupakan 95 Percentile Execution Time yang
dialami oleh cluster 4 node. Dari grafik yang telah dibuat dapat dihitung poin
selisih penggunaan 2 node ke 3 node, 3 node ke 4 node, dan 2 node ke 4 node.
Kemudian dari selisih tersebut dibuat persentase berdasarkan poin pada 2 node.
Setelah selisih didapatkan, pada masing-masing selisih diambil rata-rata dengan
menjumlahkan seluruh persentase pada jumlah transaksi 1000 sampai 10000.
Sehingga dari 2 node ke 3 node menghasilkan 9.1083%, dari 3 node ke 4 node
menghasilkan 8.2541%, dan dari 2 node ke 4 node menghasilkan 17.3623%.
Dari hasil rata-rata persentase selisih jumlah transaksi 1000 sampai 10000
pada pengujian database sistem informasi sekolah Kabupaten Semarang,
kemudian dapat diambil rata-rata persentase keseluruhan yaitu dari pertambahan 2
node ke 3 node menghasilkan nilai 20.6501% untuk transaksi jenis Read Only dan
11.5130% untuk transaksi jenis Read Write. Sedangkan untuk pertambahan 3
node ke 4 node menghasilkan nilai 7.1983% untuk transaksi jenis Read Only dan
nilai 10.5818% untuk transaksi jenis Read Write. Pada pertambahan node dari 2
node ke 4 node menghasilkan nilai 27.8484% untuk transaksi jenis Read Only dan
nilai 22.0948% untuk transaksi jenis Read Write.
Dari analisa yang dilakukan secara keseluruhan, jenis transaksi Read Write
menyebabkan kinerja yang lebih besar pada server, hal ini disebabkan pada proses
Read Write menggunakan perintah untuk menulis data pada server, sedangkan
pada jenis transaksi Read Only, transaksi yang terjadi hanyalah proses membaca
data saja. Pada Total Execution Time menghasilkan nilai yang semakin besar pada
setiap peningkatan jumlah transaksi, hal ini disebabkan jumlah transaksi yang
semakin banyak membutuhkan waktu lebih lama dalam penanganannya. Pada
jenis transaksi Read Only dan Read Write menghasilkan nilai yang relatif sama
karena pemakaian Memory didasarkan pada jumlah client yang terhubung
sehingga Memory akan dialokasikan sesuai jumlah client yang ada. Pemakaian
CPU juga memberikan nilai yang relatif sama pada setiap penambahan jumlah
transaksi, menunjukkan bahwa pemakaian CPU juga didasarkan pada jumlah
client yang terhubung sehingga kemudian pemakaian CPU dialokasikan sesuai
dengan jumlah client. Pada Average Execution Time dan 95 Percentile Execution
Time menghasilkan nilai yang naik turun disebabkan karena kondisi jaringan,
kondisi hardware yang tidak stabil. %Usage CPU dan %Usage Memory juga
menghasilkan nilai yang tidak stabil karena proses yang terjadi di dalam RAM
dan CPU juga tidak stabil.
Untuk tahap Optimize, respon dari hasil pengukuran yang dilakukan adalah
beban Memory dan beban CPU yang belum terpakai secara optimal pada proses
pengukuran. Konfigurasi ulang pada file my.cnf pada bagian Fine Tuning perlu
dilakukan yang disesuaikan dengan penggunaan database serta besar Memory dan
prosesor yang dapat dipakai.
5. Kesimpulan
Beberapa kesimpulan yang dapat diambil dari hasil penelitian, pengujian
sistem dan analisa data, yaitu: Sistem MySQL Server dapat dibangun pada sistem
cluster secara load balance dengan sistem replikasi; Dari data yang didapatkan
20
setelah perhitungan dapat diambil kesimpulan bahwa jumlah node yang terbaik
untuk dipakai adalah 4 karena disesuaikan dengan Hukum Amdahl dimana kinerja
sistem semakin baik apabila sebagian perangkat lunak atau kerasnya diperbarui
atau ditingkatkan kinerjanya, sehingga semakin bertambahnya node akan
menjadikan kemampuan server lebih baik sehingga untuk node 4 menjadi node
terbaik untuk digunakan jika pengaplikasian cluster mencapai 4 node.
Dari penelitian ini juga telah diketahui faktor yang mempengaruhi kinerja
server yaitu : Jumlah client yang mempengaruhi beban CPU dan Memory; Jumlah
transaksi yang mempengaruhi Total Execution Time; Jenis transaksi yang
mempengaruhi beban CPU, beban Memory dan Execution Time. Sedangkan faktor
eksternal seperti kondisi jaringan, kondisi unit PC juga mempengaruhi kinerja PC.
6. Daftar Pustaka
[1] Shah Sujit Kumar, 2009, Reduce High CPU Usage Overload Problem Caused By MySQL, Diperoleh dari http://www.sks.com.np/article/4/reduce-
high-cpu-usage-overload-problem-caused-by-mysql.html, diakses tanggal 6
Desember 2013.
[2] Pamungkas Victor Hari, 2011, Analisis Perbandingan Algoritma Penjadwalan Load Balancer Terhadap Kinerja Web Server Cluster, Salatiga: Jurusan
Teknik Informatika Universitas Kristen Satya Wacana.
[3] Thamrin Davi, 2008, Implementasi dan Evaluasi Kinerja Load Balancing Pada Server-Server Proxy di IPB, diperoleh dari
http://repository.ipb.ac.id/bitstream/handle/123456789/18877/Thamrin.%20
David_G2008.pdf?sequence=2, diakses tanggal 6 Desember 2013.
[4] Finsanugraha Destarius, 2013, Perancangan Sistem Informasi Sekolah Menggunakan Vaadin dengan Pemanfaatan Google Maps di Kota Semarang,
Salatiga: Jurusan Teknik Informatika Universitas Kristen Satya Wacana.
[5] Gao Jane., Ho Dixon., Dhodapkar Shridhar., 2013, Nexus 7000 High CPU Usage Troubleshooting Guide, diperoleh dari
http://www.cisco.com/c/en/us/support/docs/interfaces-modules/nexus-7000-
series-supervisor-1-module/116137-trouble-nexus7000-highcpu-00.html,
diakses tanggal 6 Desember 2013.
[6] Stewart David B., 2006, Measuring Execution Time and Real-time Performance: Part 1, diperoleh dari http://www.drdobbs.com/embedded-
systems/measuring-execution-time-and-real-time-p/193502123, diakses
tanggal 6 Desember 2013.
[7] Sivasubramanian Balaji., Frahim Erum., Froom Richard, 2010, PPDIOO Lifecycle Approach to Network Design and Implementation, diperoleh dari
http://www.ciscopress.com/articles/article.asp?p=1608131&seqNum=3,
diakses tanggal 1 Desember 2013.