Hasil dan Pembahasan T1 672006230 Full text

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 fileetcmysqlmy.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. Readwrite 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 avgstddev merupakan hasil dari waktu rata-rata event dibagi standar deviasi, execution time avgstddev 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 CP U 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. 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 P E R S E N T A S E JUMLAH TRANSAKSI B E B A N C P U R EA D O N LY 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. 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 P O IN JUMLAH TRANSAKSI B E B A N C P U R EA D W R I T E 2N 3N 4N 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 P O IN JUMLAH TRANSAKSI B E B A N M E M O RY R EA D O N LY 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 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 P O IN JUMLAH TRANSAKSI B E B A N M E M O RY R EA D W R I T E 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. 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 D E T IK JUMLAH TRANSAKSI TOTA L E X EC U T I O N T I M E R EA D O N LY 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 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 D E T IK JUMLAH TRANSAKSI TOTA L E X EC U T I O N T I M E R EA D W R I T E 2N 3N 4N 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 ID E T IK MS JUMLAH TRANSAKSI AV E R AG E E X EC U T I O N T I M E R EA D O N LY 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. 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 ID E T IK MS JUMLAH TRANSAKSI AV E R AG E E X EC U T I O N T I M E R EA D W R I T E 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 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 D E T IK MS JUMLAH TRANSAKSI 9 5 P E R C E N T I L E E X EC U T I O N T I M E R EA D O N LY 2N 3N 4N 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 ID E T IK MS JUMLAH TRANSAKSI 9 5 P E R C E N T I L E E X EC U T I O N T I M E R EA D W R I T E 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