perancangan dan implementasi finite automata€¦ · pada sistem informasi sekolah wilayah...

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.



Masing-masing node mereplikasi database sesuai dengan master acuannya.

Master dari ds1 adalah ds2, master dari ds2 adalah ds3, master dari ds3 adalah

ds1.



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









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




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




node ke 3 node menghasilkan -0.8772%, dari 3 node ke 4 node menghasilkan


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 menghasilkan 18.7544%, dari 3 node ke 4 node menghasilkan -


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







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 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


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 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


nilai 10.5818% untuk transaksi jenis Read Write. Pada pertambahan node dari 2


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.

perancangan dan implementasi finite automata€¦ · pada sistem informasi sekolah wilayah...

Documents