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
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 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 PE R SE N TA SE JUMLAH TRANSAKSI
BEBAN CPU READ ONLY
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
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
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 DE TIK JUMLAH TRANSAKSI
TOTAL EXECUTION TIME READ ONLY
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 DE TIK 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 IDE TIK (MS ) JUMLAH TRANSAKSIAVERAGE EXECUTION TIME READ
ONLY
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 IDE TIK (MS ) JUMLAH TRANSAKSI
AVERAGE EXECUTION TIME READ
WRITE
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 MI LI DE TI K( MS) 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 IDE TIK (MS ) JUMLAH TRANSAKSI95 PERCENTILE EXECUTION TIME
READ WRITE
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.
