Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 1
IMPLEMENTASI KOMUNIKASI ANTAR SERVER PADA BISNIS PULSA ELEKTRIK MENGGUNAKAN ZEROMQ
Yudha Ari Sasongko – Wahyu Suadi S.Kom, M.Kom Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Surabaya,
Email: [email protected] Abstrak
Untuk mendistribusikan stok voucher isi ulang pulsa, pihak operator telekomunikasi seluler menunjuk authorized dealer di setiap region atau propinsi yang kemudian didistribusikan kepada beberapa supplier atau
server oleh authorized dealer. Dalam pendistribusian stok berdasarkan region, server-server pulsa mengalami
kendala karena tidak semua pengguna seluler yang melakukan pengisian ulang pulsa berada di region atau
tempat nomor seluler yang digunakan terdaftar. Untuk mendapatkan stok region lain, server pada suatu region
harus terhubung dan dapat berkomunikasi dengan server yang berada pada region lain.
ZeroMQ sebagai sistem messaging merupakan implementasi dari lightweight messaging yang
mendukung beberapa model messaging berbeda dan mampu mengirim/menerima pesan hingga 4.100.000 pesan
per detik digunakan sebagai framework dan library perangkat lunak yang dibangun untuk menyelesaikan
permasalahan yang ada dalam komunikasi antar server pada bisnis pulsa elektrik. Dari pengujian yang telah
dilakukan, ZeroMQ dengan lebih dari satu client mampu meningkatkan kinerja latency hingga 97,16% dari
socket linux. Kata kunci: ZeroMQ, client, server, HLR, seluler
1. Pendahuluan
Pada penggunaan sehari-hari, telpon seluler memerlukan pulsa untuk dapat digunakan. Seiring berkembangnya teknologi, pihak operator telekomunikasi seluler menyediakan voucher elektrik untuk mempermudah para pengguna dalam melakukan pengisian ulang pulsa. Dalam pendistribusian stok voucher isi ulang pulsa pihak operator telekomunikasi seluler menunjuk authorized dealer di setiap region atau propinsi. Untuk memenuhi kuantitas dan ketertiban pendistribusian stok berdasarkan region masing-masing, authorized dealer melakukan distribusi kepada supplier atau server.
Server-server pulsa mengalami kendala pendistribusian stok berdasarkan region karena tidak semua pengguna seluler yang melakukan pengisian ulang pulsa berada di region atau tempat nomor seluler yang digunakan terdaftar. Hal ini mengakibatkan mereka harus menyediakan stok untuk region lain dimana stok tersebut hanya dapat digunakan di region stok tersebut berasal. Untuk mendapatkan stok region lain, server pada suatu region harus terhubung dan dapat berkomunikasi dengan server yang berada pada region lain. Middleware dalam bentuk messaging server (messaging middleware), merupakan platform dimana perangkat-perangkat lunak dapat membuat aplikasi berskala besar dengan menggabungkan aplikasi-aplikasi yang dibuat dengan teknologi yang berbeda, berjalan di lingkungan yang berbeda. ZeroMQ sebagai sistem messaging merupakan implementasi dari lightweight messaging yang mendukung beberapa model messaging berbeda
sehingga memudahkan penentuan model messaging dalam suatu perangkat lunak. ZeroMQ mampu mengirim/menerima pesan hingga 4.100.000 pesan per detik digunakan sebagai framework dan library perangkat lunak yang dibangun untuk menyelesaikan permasalahan yang ada dalam komunikasi antar server pada bisnis pulsa elektrik. Beberapa batasan yang ada adalah sebagai berikut: - Komunikasi server mencakup dikirimnya data
transaksi oleh server region pengirim ke server region penyedia stok sampai diterimanya status pemrosesan data transaksi oleh server region pengirim.
- Pengiriman data transaksi ke operator telekomunikasi seluler diasumsikan berhasil tanpa adanya pengiriman data tersebut ke operator telekomunikasi seluler.
- Hanya mencakup bisnis pulsa elektrik untuk operator telekomunikasi seluler Telkomsel Simpati.
- Aplikasi ini diimplementasikan pada sistem operasi Linux Ubuntu Desktop 9.04.
- Media penyimpanan data transaksi menggunakan database server MySQL.
- Menggunakan bahasa C++ untuk server pusat (aplikasi server) dan Java untuk server region (aplikasi client).
2. ZeroMQ
ZeroMQ merupakan implementasi dari lightweight messaging dengan socket seperti API. ZeroMQ sangat cepat, mampu mengirim/menerima pesan hingga 4.100.000 pesan per detik. Hanya membutuhkan sepasang pages pada memory yang ada, sehingga
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 2
dapat berjalan pada platform dengan memory terbatas. Penggunaan sedikit memory juga penting untuk mengoptimalkan penggunaan L1i cache. Ketika ukuran kode cukup kecil, processor dapat menahan seluruh kode messaging dalam L1i cache menghindari akses lambat pada physical memory untuk mendapatkan potongan kode baru. ZeroMQ adalah software open source berlisensi LGPL yang ditulis dalam bahasa C++ menyediakan API bahasa C, C++, Common Lisp, Java, Python dan Ruby serta mendukung protokol transport yang berbeda seperti TCP, UCP, PGM, IPC, inter-thread dan lain-lain [10]. Inti dari ZeroMQ mengimplementasikan beberapa fitur low-level, yaitu: - Bagaimana menempatkan titik akhir (endpoints)
dari aliran pesan pada jaringan. - Bagaimana membentuk koneksi antara
endpoints. - Bagaimana menutup koneksi. - Bagaimana melewatkan pesan antara koneksi
dan thread aplikasi. Persistence bukan merupakan prioritas utama pada ZeroMQ karena menurut developer ZeroMQ sendiri hal tersebut bertentangan dengan messaging latensi rendah (low latency).
2.1. Distributed Broker
Ada beberapa keuntungan pada model broker-based yang tidak tersedia pada model broker-less. Aplikasi pengirim dan aplikasi penerima tidak harus tumpang tindih selamanya. Pesan disimpan pada broker ketika pengirim sudah mati (off) dan penerima belum juga nyala (on). Begitu juga jika aplikasi mengalami kegagalan, pesan yang sudah dikirim ke broker tidak hilang. Untuk membentuk perilaku yang semacam ini hanya perlu mempunyai beberapa aplikasi (broker) di tengah di antara aplikasi pengirim dan aplikasi penerima. Akibatnya, pesan yang dikirim harus melewati 2 lompatan jaringan. Arsitektur distributed broker
digunakan untuk menanggulangi permasalahan broker sebagai hambatan (bottleneck).
Gambar 2.1 Diagram Distributed Broker
Seperti pada Gambar 2.1, setiap antrian (queue) pesan diimplementasikan sebagai aplikasi terpisah. Hal itu
dapat dijalankan pada kotak yang sama sebagai satu dari aplikasi yang sedang terhubung, atau dimungkinkan juga terletak pada kotak yang sama sekali berbeda. Beberapa queue mungkin berjalan pada kotak tunggal dimana kotak tersebut didedikasikan khusus untuk menjadi tempat sebuah queue tunggal. Queue teregistrasi dengan broker (directory service) sehingga dapat diakses oleh semua aplikasi pada jaringan. Selain itu, queue adalah bagian yang sangat sederhana dari aplikasi yang mendapatkan pesan dari pengirim dan mendistribusikan kepada penerima. Sehingga kemungkinan terjadinya kegagalan lebih rendah dibandingkan dengan aplikasi yang penuh dengan bussines logic komplek. Distributed broker pada ZeroMQ diimplementasikan pada contoh aplikasi instant messaging pembahasan selanjutnya, dimana contoh aplikasi instant messaging tersebut mengemulasikan arsitektur broker-based klasik dengan menggunakan arsitektur broker-less ZeroMQ.
2.2. Instant Messaging
Messaging tanpa broker sedikit asing bagi para developer yang terbiasa dengan produk messaging biasa seperti IBM WebSphere MQ. Meskipun ZeroMQ melakukan yang terbaik untuk membuat perbedaan antara model broker-based dan broker-less lebih pada sebuah detail teknis daripada sesuatu yang para developer harus repot-repot lakukan, masih ada beberapa aspek yang harus dipertimbangkan. Yang terpenting, jika pengirim pesan dan penerima pesan tidak berjalan pada waktu yang bersamaan, maka tidak ada tempat sementara untuk menyimpan pesan-pesan. Dengan arsitektur broker-based pesan-pesan dapat disimpan pada broker, tetapi, tidak ada broker dalam kasus ini, developer harus membuat aplikasi penyimpanan pesan sendiri. Jika Anda menerapkan instant messaging (IM) dengan arsitektur broker-based klasik star messaging (satu broker sebagai pemusatan diskusi antar banyak client), broker akan menahan pesan-pesan dan semua IM client akan terhubung pada broker untuk mengakses chatroom.
Gambar 2.2 ZeroMQ IM Example Components
Dengan arsitektur broker-less kita akan membuat aplikasi menyimpan pesan sendiri. Sehingga secara langsung Anda akan menerapkan ulang arsitektur star sendiri. Desain yang dihasilkan akan menjadi aplikasi terdistribusi dengan tiga jenis komponen: 1. chatroom menerima dan mendistribusi ulang
pesan-pesan dari pengguna.
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 3
2. prompt menerima input pengguna dan mengirimkannya ke chatroom.
3. display terhubung pada chatroom dan menampilkan pesan-pesan yang berasal dari chatroom.
3. Bisnis Pulsa Elektrik
Bisnis pulsa elektrik adalah bisnis yang bergerak di bidang jasa pelayanan isi ulang pulsa dengan menggunakan media elektronik. Media elektronik di sini dapat berupa sms atau jaringan internet. Ada 3 kategori pendistribusi dalam bisnis ini: 1. Authorized dealer, merupakan badan usaha di
setiap region atau propinsi yang ditunjuk oleh operator telekomunikasi seluler untuk melayani pengguna dalam melakukan isi ulang pulsa.
Authorized Dealer
Pengguna
Supplier/Server
Agen
Supplier/Server
Operator Telekomunikasi
Seluler
Gambar 3.1 Distribusi Stok
Authorized dealer diberikan kewenangan untuk mendistribusikan dan menjual persediaan (stok) isi ulang pulsa sesuai dengan aturan yang telah ditetapkan oleh pihak operator telekomunikasi seluler karena kebijakan setiap region atau propinsi berbeda. Contohnya dalam penetapan harga jual. Stok isi ulang pulsa berbentuk unit yang tersimpan dalam chip atau SIM Card seperti halnya pulsa yang ada pada setiap SIM Card para pengguna seluler. Stok tersebut dapat digunakan dengan melakukan sms yang format dan nomor tujuannya telah ditentukan oleh pihak operator telekomunikasi seluler. Authorized dealer melakukan distribusi ke beberapa supplier atau server yang melayani isi ulang pulsa.
2. Supplier atau server merupakan badan usaha atau perorangan yang ditunjuk oleh authorized dealer untuk membantu melakukan pendistribusian stok isi ulang pulsa. Server tidak selalu mendapatkan stok dari authorized dealer tapi bisa juga dari server-server lain. Stok yang diperoleh dari authorized dealer berbentuk unit yang tersimpan dalam chip atau SIM Card. Sedangkan stok yang
diperoleh dari server lain berbentuk nominal saldo. Selain bentuk stok, mekanisme penggunaan stok juga berbeda antara server ke authorized dealer dengan server ke server. Untuk server ke authorized dealer menggunakan sms melalui chip dengan format dan nomor tujuan yang telah ditentukan oleh operator telekomunikasi seluler. Sedangkan untuk server ke server menggunakan jaringan internet.
internet
Supplier/Server Supplier/Server
Operator Telekomunikasi
Seluler
Gambar 3.2 Pengambilan Stok Server
*777*hp*nominal*pin# adalah contoh format sms yang dikirim server ke operator telekomunikasi seluler. Keterangan: 777 : nomor tujuan untuk permintaan stok
simpati hp : nomor seluler yang akan diisi ulang
pulsa nominal : besar nominal pulsa yang akan
diisikan pin : kode rahasia pengaman transaksi
pengisian pulsa yang ada di setiap chip yang digunakan
*777*08123456789*10*1234# menunjukkan permintaan stok pulsa 10.000 (sepuluh ribu) untuk nomor simpati 08123456789.
3. Agen merupakan perorangan yang membantu server dalam pendistribusian stok ke pengguna dengan melakukan registrasi nomor seluler dan data identitas terlebih dahulu pada server yang dikehendaki. Agen memperoleh stok dari server berbentuk nominal saldo.
internet
Supplier/Server Supplier/Server
Operator Telekomunikasi
Seluler
PenggunaAgen Gambar 3.3 Pengambilan Stok Agen
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 4
Untuk mekanisme penggunaan stok, agen mengirim sms melalui nomor seluler yang telah diregistrasikan dengan format dan nomor tujuan yang telah ditentukan oleh server. Setelah agen mengirim sms kemudian server meneruskan permintaan tersebut ke operator telekomunikasi seluler untuk dilakukan proses pengisian pulsa pada nomor pengguna. i.nominal.hp.pin adalah contoh format sms yang dikirim agen ke server. Keterangan: i : kode untuk permintaan stok pulsa nominal : besar nominal pulsa yang akan
diisikan hp : nomor seluler yang akan diisi ulang
pulsa pin : kode rahasia pengaman transaksi
pengisian pulsa yang diberikan server kepada agen
i.5.08123456789.2345 menunjukkan permintaan stok pulsa 5.000 (lima ribu) untuk nomor 08123456789.
4. Deskripsi Umum Sistem
Perangkat lunak yang dikembangkan adalah suatu sistem yang mengimplementasikan komunikasi antar server pada bisnis pulsa elektrik dengan menggunakan ZeroMQ. Perangkat lunak ini berfungsi untuk menghubungkan server-server region yang terletak di setiap region atau propinsi agar dapat saling bertukar persediaan (stok) isi ulang pulsa elektrik. Server-server region dibagi berdasarkan data Home
Location Register (HLR) yang telah ditetapkan oleh operator telekomunikasi seluler. Data HLR yang digunakan hanya berasal dari operator telekomunikasi seluler Telkomsel Simpati. Sistem yang dibangun berjalan secara online yang berarti membutuhkan sebuah network atau jaringan. Proses dimulai ketika server region (aplikasi client) melakukan koneksi ke database dan melakukan penge cekan data transaksi dengan status belum terproses, jika pada database terdapat data transaksi dengan status belum terproses maka aplikasi client akan mengirimkan data transaksi tersebut pada server pusat (aplikasi server) dan mengubah status data transaksi tersebut menjadi terproses. Aplikasi server melakukan parsing dan melakukan matching terhadap nomor seluler yang ada pada data transaksi yang dikirim oleh aplikasi client untuk menentukan region tujuan. Kemudian aplikasi server mengirimkan data transaksi tersebut pada aplikasi client dengan region yang sama dengan region tujuan yang telah ditentukan. Dimana region aplikasi client telah teregistrasi sebelumnya pada aplikasi server ketika aplikasi client melakukan koneksi ke aplikasi server. Setelah menerima data transaksi, aplikasi client tujuan mengirimkan pesan balasan pada aplikasi server kemudian aplikasi server meneruskan pesan balasan pada aplikasi client tempat data transaksi tersebut berasal.
Aplikasi client berfungsi mengirim/menerima data transaksi dan status pemrosesan data transaksi sedangkan aplikasi server berfungsi sebagai penghubung (broker) aplikasi-aplikasi client dan penentu tujuan dikirimnya data transaksi (forwarder).
Server
Client Region 1
Data
Transaksi
Data HLR
get
and
update
load
Parse
Message
Match HLR
send send
Client Region 2
Data
Transaksi
get
and
update
receivereceive
Define
Destination
Gambar 4.1 Deskripsi Umum Sistem
5. Desain Aplikasi Server
Aplikasi server yang dibangun berfungsi sebagai forwarder atau penentu tujuan dari pesan yang dikirim oleh aplikasi client. Selain itu juga, aplikasi server juga bertindak sebagai broker aplikasi-aplikasi client yang ada pada sistem. Ketika aplikasi server menerima pesan yang berisi data transaksi yang dikirim oleh aplikasi client, aplikasi server melakukan pengolahan terhadap pesan terlebih dahulu untuk menentukan aplikasi client yang merupakan tujuan dari pesan tersebut. Penentuan aplikasi client yang dituju dilakukan berdasarkan data HLR yang telah disimpan pada file teks yang kemudian di-load dan disimpan dalam variabel saat aplikasi server dijalankan. Seperti pada Gambar 5.1, setiap pesan yang diterima oleh aplikasi server akan di-parse dan diambil nomor seluler yang ada pada pesan tersebut. Kemudian nomor seluler yang telah diambil dicocokan dengan data HLR untuk menentukan region terdaftarnya nomor seluler sekaligus untuk menentukan aplikasi client tujuan pengiriman pesan. Saat aplikasi server dijalankan, proses yang pertama kali dilakukan adalah melakukan inisialisasi infrastruktur dari ZeroMQ. Proses inisialisasi infrastruktur ZeroMQ dilakukan untuk membentuk koneksi ke ZeroMQ server dan menyediakan jalur komunikasi antar thread ZeroMQ yang terbentuk. Setelah infrastruktur ZeroMQ terinisialisasi, selanjutnya dilakukan inisialisasi layout thread. Inisialisasi layout thread bertujuan untuk membentuk handling I/O thread lalu lintas jaringan dengan menggunakan mekanisme polling optimal pada platform (sistem operasi) yang digunakan. Proses selanjutnya adalah membuat queue global. Queue digunakan untuk menerima pesan dari exchange-exchange yang telah ter-bind. Agar queue tersebut dapat di-bind oleh exchange yang terdapat pada aplikasi lain, maka queue yang dibuat harus visible di seluruh jaringan atau bersifat global.
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 5
Mulai
Inisialisasi
infrastruktur
ZeroMQ
Inisialisasi layout
thread ZeroMQBuat queue global
Load data HLR
Buat exchange
globalTerima pesan
Ambil nomor
seluler, match
HLR dan tentukan
tujuan
Data HLR
Tentukan tujuan
Buat pesan keluar
Selesai
Data transaksi
baru
Parse pesan
ya tidak
Kirim pesan
Gambar 5.1 Desain Proses Aplikasi Server
Selanjutnya aplikasi server me-load data HLR yang kemudian disimpan dalam variabel. Data HLR yang di-load berisi nama region dan prefix region nomor seluler sesuai dengan masing-masing region yang ada. Tujuannya yaitu: nama region digunakan untuk penamaan identitas exchange yang akan dibuat, dan untuk menentukan tujuan pengiriman pesan; dan prefix region nomor seluler digunakan untuk proses match HLR yang hasilnya juga digunakan untuk menentukan region tujuan pengiriman pesan. Exchange dibuat untuk digunakan mengirim pesan pada queue yang telah di-bind. Variabel yang digunakan untuk menyimpan data HLR berbentuk linked list yang mempunyai 2 member, yaitu region dan HLR. Region digunakan untuk menyimpan nama region, dan HLR untuk menyimpan prefix region nomor seluler.
region HLR
Gambar 5.2 Linked List
Operasi string yang digunakan untuk pengolahan pesan pada proses parse pesan; ambil nomor seluler, match HLR dan tentukan tujuan adalah operasi string explode untuk memecah kata atau kalimat menjadi huruf atau kata berdasarkan tanda pemisah (separator) yang ditentukan; operasi string find and replace untuk mengubah karakter atau kata yang dicari pada suatu kata atau kalimat dengan karakter atau kata yang ditentukan; dan operasi string find. Pada standar string library C++ operasi string explode dan operasi string
find and replace belum tersedia. Berikut adalah pseudocode operasi string explode.
1 StringExplode(str, separator) 2 res[] ← null 3 i ← 1 4 j ← 0 5 for k ← 1 to str.length 6 do if str.substr(k, 1) = separator 7 then res[j] ← str.substr(i, k - i) 8 i ← k + 1 9 j ← j + 1 10 k ← k + 1 11 res[j] ← str.substr(i, k - i) 12 return res
Dan berikut adalah pseudocode operasi string find and
replace. 1 StringFindReplace(str, find, replace) 2 for i ← 1 to str.length 3 do if str.substr(i, 1) = find 4 then str.substr(i, 1) ← replace 5 return str
Pada proses parse pesan operasi string explode digunakan untuk memecah pesan yang diterima oleh aplikasi server yang berisi data transaksi. Setelah terpecah menjadi beberapa bagian selanjutnya dicek apakah pesan tersebut merupakan pesan yang berisi data transaksi baru atau berisi balasan status pemrosesan. Hal ini dapat dibedakan dari tujuan pengiriman yang ada pada pesan. Jika berisi balasan status pemrosesan maka akan dilakukan proses tentukan tujuan. Namun jika berisi data transaksi baru maka proses ambil nomor seluler, match HLR dan tentukan tujuan dilakukan. Pesan yang telah terpecah salah satu bagiannya merupakan nomor seluler, selanjutnya nomor seluler tersebut disimpan pada sebuah variabel. Nomor seluler yang telah tersimpan pada variabel digunakan sebagai patokan pencocokan prefix region nomor seluler dengan menggunakan operasi string find. Dalam proses ini yang dimaksud dengan match HLR adalah proses pencocokan 7 digit pertama nomor seluler dengan data prefix region nomor seluler yang ada pada data HLR. Jika telah ditemukan prefix region nomor seluler yang sesuai, maka tujuan pengiriman pesan juga telah ditemukan. Setelah tujuan pengiriman ditemukan selanjutnya dilakukan proses pembuatan pesan keluar dan kemudian pesan tersebut dikirim pada aplikasi client tujuan.
6. Desain Aplikasi Client
Aplikasi client yang dibangun pada sistem berfungsi sebagai pengirim/penerima pesan yang berisi data transaksi baru, dan status pemrosesan data transaksi. Pada aplikasi client terdapat beberapa proses yang telah digambarkan pada Gambar 6.1. Proses pada aplikasi client diawali dengan proses inisialisasi koneksi pada database, dan dilanjutkan dengan proses inisialisasi koneksi pada ZeroMQ server dan server
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 6
center (aplikasi server). Proses ini dilakukan untuk membentuk koneksi pada database yang berfungsi menyimpan data-data transaksi, dan membentuk koneksi pada ZeroMQ server dan aplikasi server. Setelah koneksi database, ZeroMQ server dan aplikasi server terbentuk selanjutnya dilakukan proses pembuatan queue dan exchange. Pada aplikasi client queue dan exchange yang dibuat bersifat lokal karena queue dan exchange tersebut hanya digunakan pada aplikasi client itu saja dan tidak untuk diakses oleh aplikasi lain. Queue dan exchange yang telah terbentuk kemudian di-bind pada queue dan exchange yang ada pada aplikasi server. Binding bertujuan untuk mengikat atau membentuk komunikasi antara queue dan exchange sehingga dapat dilakukan
pertukaran pesan dapat dilakukan.
Mulai
Inisialisasi koneksi
database
Inisialisasi koneksi
ZeroMQ dan
server center
Buat queue lokalBuat exchange
lokal
BindingSelect data
transaksi
Buat pesan data
transaksi
Kirim pesan data
transaksi
Update data
transaksiTerima pesan
Data transaksi
baru dari client
lain
Kirim balasan
status
pemrosesan
Buat pesan
balasan status
pemrosesan
Selesai
ya
tidak
Data
Transaksi
Gambar 6.1 Desain Proses Aplikasi Client
Selanjutnya aplikasi client melakukan pengecekan data transaksi yang ada pada database. Jika pada database ditemukan data transaksi dengan status belum terproses, maka data transaksi tersebut akan diambil (select) dan diformat dalam sebuah pesan yang nantinya akan dikirim pada aplikasi server. Setelah proses pengiriman pesan dilakukan selanjutnya status data transaksi di-update. Selain mengirim pesan, aplikasi client juga menerima pesan yang berisi data transaksi baru, dan balasan status pemrosesan dari aplikasi client lain. Pesan yang diterima diolah dengan menggunakan operasi string. Operasi string yang digunakan untuk pengolahan pesan adalah operasi string split. Operasi string split berfungsi untuk memecah kata atau kalimat menjadi huruf atau kata berdasarkan tanda pemisah (separator) yang ditentukan sama halnya dengan operasi string explode pada aplikasi server. Pesan yang telah diolah kemudian dicek apakah pesan yang diterima merupakan pesan data transaksi baru atau pesan balasan status pemrosesan
data transaksi. Jika pesan yang diterima merupakan pesan data transaksi baru, maka aplikasi client akan membuat pesan balasan status pemrosesan untuk dikirim pada aplikasi client pengirim data transaksi.
6.1. Perancangan Data
Pesan yang dikirim oleh aplikasi client terdiri dari dua jenis, yaitu pesan yang berisi data transkasi baru dan pesan yang berisi status pemrosesan data transaksi. Berikut format pesan yang dikirim oleh aplikasi client: 1. Format pesan data transaksi baru
<src><dst><nom><hp><refid>
Keterangan: <src> : pengirim pesan <dst> : penerima pesan <nom> : nominal pulsa <hp> : nomor seluler <refid> : referensi id transaksi dari pengirim
pesan data transaksi 2. Format pesan balasan status pemrosesan
<src><dst><hp><refid><OK> Keterangan: <src> : pengirim pesan <dst> : penerima pesan <hp> : nomor seluler <refid> : referensi id transaksi dari pengirim
pesan data transaksi <OK> : status pemrosesan data transaksi
Data nominal, nomor seluler dan referensi id transaksi yang ada pada pesan berasal dari data yang ada pada database. Struktur tabel pada database yang digunakan aplikasi client dirancang berdasarkan struktur tabel pada database yang digunakan oleh sistem isi ulang pulsa elektrik yang telah dikembangkan oleh para developer perangkat lunak bisnis pulsa elektrik. Berikut struktur tabel pada database yang digunakan.
Tabel 6.1 Struktur Tabel Data Transaksi
No. Atribut Tipe Ukura
n Null Ket.
1 id_transaksi integer
unsigned zerofill
2 nominal integer
3 no_hp varchar
15
4 ref_id_transaksi
integer
unsigned zerofill
5 status_transaksi
integer
7. Uji Coba dan Evaluasi
Pengujian dilakukan dengan tujuan untuk mengetahui perbandingan performa average latency atau selisih rata-rata waktu kirim dan terima paket atau pesan, dan average throughput atau tingkat rata-rata jumlah
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 7
diterimanya pesan dalam satuan waktu dengan single client maupun multi client yang terhubung dan beraktifitas pada server antara sistem yang menggunakan ZeroMQ dengan domain socket linux Internet networking socket (AF_INET).
n-times Snd msg
n-times Rcv msgServerClient
3 timesrepetitions
Gambar 7.1 Uji Average Latency Single Client
Snd first msg
n-times Rcv msgServerClient
3 timesrepetitions
Gambar 7.2 Uji Average Throughput Single Client
n-times Snd msg
n-times Rcv msg
Server
Client 1
3 timesrepetitions
Client n
Gambar 7.3 Uji Average Latency Multi Client
Snd first msg
n-times Rcv msg
Server
Client 1
3 timesrepetitions
Client n
Gambar 7.4 Uji Average Throughput Multi Client
Untuk memperoleh hasil yang optimal, masing-masing proses pengukuran dilakukan sebanyak tiga kali dimana satu proses pengukuran dengan proses pengukuran yang lain diberikan jeda waktu selama 5 detik. Kemudian nilai rata-rata dari ketiga hasil pengukuran tersebut dijadikan sebagai hasil uji coba.
7.1. Lingkungan Uji Coba
Uji coba dilakukan menggunakan komputer yang berbeda dan jaringan inter koneksi dengan intranet point-to-point. Komputer untuk aplikasi server dan aplikasi client terhubung tanpa switch dengan menggunakan kabel UTP cross. Berikut spesifikasi perangkat keras dan perangkat lunak yang digunakan untuk aplikasi server: - Spesifikasi perangkat keras
Prosesor Intel Pentium 4 1,8GHz Memory DDR 512 MB Hard Disk 40 GB Broadcom NetXtreme Gigabit Ethernet
- Spesifikasi perangkat lunak Gcc versi 4.3 Sistem operasi Linux Ubuntu Desktop 9.04 IP address 192.168.1.113
Untuk aplikasi client perangkat keras yang digunakan adalah Notebook MSI Mega Book S420 dengan spesifikasi: - Prosesor Intel Core 2 Duo T5500 1,66GHz - Memory DDR2-667 2.976 MB - Realtek RTL8139/810x Family Fast Ethernet
NIC Dan untuk spesifikasi perangkat lunak yang digunakan aplikasi client adalah: - Gcc versi 4.3 - ZeroMQ versi 1.0.1 - Sistem operasi Linux Ubuntu Desktop 9.04 - VMware Workstation ACE Edition versi 6.0.0
dengan spesifikasi perangkat keras: Hard Disk 8 GB Memory 512 MB
- IP address 192.168.1.112
7.2. Uji Coba Skenario I
Pesan yang dikirim : test Jumlah pengiriman : 1.000, 2.000, 3.000, . . .
10.000 kali. Jumlah client : 1 Setelah dilakukan pengujian, berikut adalah hasil pengukuran average latency dan average throughput skenario I.
Tabel 7.1 Hasil Pengukuran Average Latency Skenario I
n-kirim Average Latency (µs)
Δ socket linux zeromq
1.000 196,69 291,43 -48,17% 2.000 184,96 275,74 -49,08% 3.000 181,55 273,07 -50,41% 4.000 175,79 266,83 -51,79% 5.000 179,86 268,09 -49,05% 6.000 176,49 267,37 -51,49% 7.000 174,04 266,33 -53,03% 8.000 177,03 265,90 -50,20%
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 8
9.000 173,82 266,11 -53,10% 10.000 173,34 265,84 -53,36%
Tabel 7.2 Hasil Pengukuran Average Throughput
Skenario I
n-kirim
Average Throughput (msg/s) Δ socket
linux zeromq
1.000 5.466 4.942.689 90.326,07% 2.000 13.046 4.777.895 36.523,45% 3.000 16.479 4.929.962 29.816,63% 4.000 28.423 4.940.341 17.281,49% 5.000 369.408 4.865.876 1.217,21% 6.000 42.228 4.649.674 10.910,88%
7.000 41.943 3.555.167 8.376,19% 8.000 44.019 3.185.234 7.136,04% 9.000 47.125 3.527.884 7.386,23%
10.000 410.426 2.476.964 503,51% Pada skenario I ini diperoleh hasil pengukuran average latency socket linux lebih baik dari ZeroMQ. Selisih average latency socket linux dengan ZeroMQ antara 88,22 – 94,74 µs atau mengalami penurunan performa hingga 53,36%. Sedangkan untuk hasil uji coba performa average
throughput ZeroMQ jauh lebih baik jika dibandingkan dengan socket linux. Diperoleh nilai selisih yang cukup signifikan dengan angka maksimal 4.937.223 atau mengalami peningkatan performa hingga 90.326,07%.
Gambar 7.5 Grafik Average Latency Skenario I
Gambar 7.6 Grafik Average Throughput Skenario I
7.3. Uji Coba Skenario II
Pesan yang dikirim : <JABODETABEK><JATIM ><10><081331212112><1234>
Jumlah pengiriman : 1.000, 2.000, 3.000, . . . 10.000 kali.
Jumlah client : 1 Pada pengujian kali ini yang membedakan antara skenario I dengan skenario II adalah isi pesan yang dikirim. Tujuannya untuk mengetahui seberapa besar
0
50
100
150
200
250
300
350
Ave
rage
Lat
ency
(mic
rose
con
ds)
Roundtrip Count
zeromq
socket linux
0
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
1,00
0
2,00
0
3,00
0
4,00
0
5,00
0
6,00
0
7,00
0
8,00
0
9,00
0
10,0
00
Ave
rage
Th
rou
ghp
ut (
msg
/s)
Roundtrip Count
zeromq
socket linux
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 9
pengaruh dari panjang pesan yang dikirim dengan hasil uji coba performa yang diperoleh. Setelah dilakukan uji coba dengan menggunakan skenario II, maka diperoleh hasil pengukuran average latency dan average throughput sebagai berikut.
Tabel 7.3 Hasil Pengukuran Average Latency Skenario II
n-kirim Average Latency (µs)
Δ socket linux zeromq
1.000 194,29 303,53 -56,23% 2.000 186,39 288,66 -54,87% 3.000 182,94 284,69 -55,62% 4.000 179,71 282,88 -57,41% 5.000 178,08 282,30 -58,52% 6.000 177,62 281,56 -58,52% 7.000 177,36 279,52 -57,60% 8.000 175,25 280,14 -59,85% 9.000 187,41 279,18 -48,97%
10.000 177,47 295,70 -66,62%
Tabel 7.4 Hasil Pengukuran Average Throughput Skenario II
n-kirim
Average Throughput (msg/s) Δ socket
linux zeromq
1.000 4.525 2.620.967 57.821,92% 2.000 9.612 1.914.359 19.816,34% 3.000 12.834 522.235 3.969,15% 4.000 22.389 883.043 3.844,09% 5.000 383.322 313.736 -18,15% 6.000 40.167 345.247 759,53% 7.000 34.374 323.011 839,70%
8.000 31.459 267.225 749,44% 9.000 51.934 253.171 387,49%
10.000 114.846 276.265 140,55% Hasil pengukuran average latency yang diperoleh pada skenario II ini tidak berbeda jauh dengan hasil yang diperoleh pada skenario I. Dengan perbedaan panjang pesan yang dikirim, hasil performa average latency socket linux masih lebih baik dari ZeroMQ. Pada uji coba skenario II ini selisih average latency
socket linux dengan ZeroMQ adalah 91,76 – 118,23 µs atau mengalami penurunan performa 66,62%. Secara umum average throughput ZeroMQ masih lebih baik dari pada socket linux. Jika dibandingkan dengan hasil uji coba performa average throughput pada skenario I terlihat bahwa panjang pesan yang dikirim cukup berpengaruh pada performa yang dihasilkan terutama pada performa ZeroMQ sebagai sistem lightweight messaging.
7.4. Uji Coba Skenario III
Pesan yang dikirim : <JABODETABEK><JATIM ><10><081331212112><1234>
Jumlah pengiriman : 1.000, 2.000, 3.000, . . . 10.000 kali.
Jumlah client : 3 Berdasarkan pengukuran pada skenario II yang menunjukkan bahwa panjang pesan yang dikirim mempunyai pengaruh terhadap hasil yang diperoleh, maka pesan yang dikirim pada uji coba skenario III ini menggunakan pesan yang sama dengan uji coba skenario II. Namun pada skenario III terdapat penambahan jumlah aplikasi client yang terhubung dan beraktifitas pada aplikasi server.
Gambar 7.7 Grafik Average Latency Skenario II
0
50
100
150
200
250
300
350
Ave
rage
Lat
ency
(mic
rose
con
ds)
Roundtrip Count
zeromq
socket linux
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 10
Gambar 7.8 Grafik Average Throughput Skenario II
Setelah dilakukan pengujian, maka diperoleh hasil pengukuran average latency dan average throughput skenario III sebagai berikut.
Tabel 7.5 Hasil Pengukuran Average Latency Skenario III
n-kirim Average Latency (µs)
Δ socket linux zeromq
1.000 315,78 14,29 95,47% 2.000 301,05 10,63 96,47% 3.000 296,32 8,62 97,09% 4.000 298,26 9,27 96,89% 5.000 294,34 8,36 97,16% 6.000 296,42 9,08 96,94% 7.000 290,75 9,02 96,90% 8.000 293,08 9,52 96,75% 9.000 293,03 10,36 96,46%
10.000 294,41 9,74 96,69%
Tabel 7.6 Hasil Pengukuran Average Throughput Skenario III
n-kirim
Average Throughput (msg/s) Δ socket
linux zeromq
1.000 6.272 2.309.518 36.722,67% 2.000 13.205 1.561.994 11.728,81% 3.000 13.517 452.518 3.247,77% 4.000 17.941 565.695 3.053,09% 5.000 381.510 229.190 -39,93% 6.000 220.206 180.730 -17,93% 7.000 42.362 162.360 283,27% 8.000 231.439 167.995 -27,41% 9.000 290.477 158.041 -45,59%
10.000 338.988 173.927 -48,69%
Gambar 7.9 Grafik Average Latency Skenario III
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000
1,00
0
2,00
0
3,00
0
4,00
0
5,00
0
6,00
0
7,00
0
8,00
0
9,00
0
10,0
00
Ave
rage
Th
rou
ghp
ut (
msg
/s)
Roundtrip Count
zeromq
socket linux
0
50
100
150
200
250
300
350
Ave
rage
Lat
ency
(mic
rose
con
ds)
Roundtrip Count
zeromq
socket linux
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 11
Gambar 7.10 Grafik Average Throughput Skenario III
Berdasarkan hasil yang diperoleh dari pengujian skenario III menunjukkan bahwa performa dari ZeroMQ jauh lebih baik jika dibandingkan dengan hasil yang diperoleh dari socket linux. Hal ini menunjukkan bahwa ZeroMQ menjadi lebih optimal jika digunakan pada sistem komunikasi antar server multi client. Hasil average latency yang diperoleh cukup signifikan dengan adanya peningkatan performa pada sistem yang menggunakan ZeroMQ hingga 97,16%. Sedangkan pada pengukuran average throughput, sekali lagi ZeroMQ terbukti sebagai sistem lightweight messaging. Semakin besar pesan yang dikirimkan maka semakin kecil jumlah pesan yang dikirim/diterima oleh ZeroMQ. Baik satu aplikasi client atau lebih yang terhubung dan beraktifitas pada aplikasi server, performa throughput ZeroMQ masih menunjukkan hasil lebih baik dari socket linux.
7.5. Uji Coba Skenario IV
Pesan yang dikirim : <JABODETABEK><JATIM ><10><081331212112><1234>
Jumlah pengiriman : 1.000 kali. Jumlah client : 1, 3, 5, . . . 15 Pada skenario IV pengujian hanya dilakukan untuk mengukur average throughput. Diharapkan hasil yang diperoleh mampu mengukur tingkat kestabilan concurrent access ZeroMQ.
Tabel 7.7 Hasil Pengukuran Average Throughput Skenario IV
n-client
Average Throughput (msg/s) Δ socket
linux zeromq
1 4.525 2.620.967 57.821,92% 3 6.272 2.309.518 36.722,67% 5 9.585 2.194.740 22.797,65% 7 5.998 2.009.021 33.394,85% 9 5.466 2.020.026 36.856,20%
11 92.172 1.342.698 1.356,73% 13 6.576 1.458.435 22.078,15% 15 40.394 1.806.683 4.372,65%
Gambar 7.11 Grafik Average Throughput Skenario IV
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
1,00
0
2,00
0
3,00
0
4,00
0
5,00
0
6,00
0
7,00
0
8,00
0
9,00
0
10,0
00
Ave
rage
Th
rou
ghp
ut (
msg
/s)
Roundtrip Count
zeromq
socket linux
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000
1 3 5 7 9 11 13 15
Ave
rage
Th
rou
ghp
ut (
msg
/s)
Client Count
zeromq
socket linux
Makalah Seminar Tugas Akhir Periode Juli 2010
Yudha Ari Sasongko - 5107100606 12
Setelah dilakukan pengujian, maka didapatkan hasil pengukuran average throughput pada Tabel 7.7 dan Gambar 7.11. Berdasarkan hasil yang diperoleh menunjukkan bahwa tingkat kestabilan concurrent access ZeroMQ mengalami perubahan berdasarkan jumlah client yang terhubung. Pada Gambar 7.11 dapat dilihat bahwa global minimum terjadi ketika 11 aplikasi client terhubung dan beraktifitas pada aplikasi server. Namun ketika jumlah aplikasi client yang terhubung dan beraktifitas pada aplikasi server lebih dari sebelas sampai sama dengan lima belas, performa throughput mengalami peningkatan. Hal ini menunjukkan bahwa pada jumlah aplikasi client tertentu yang terhubung dan beraktifitas pada aplikasi server performa throughput ZeroMQ mengalami penurunan. Sedangkan untuk perbandingan performa antara socket linux dengan ZeroMQ pada skenario IV menunjukkan bahwa performa throughput ZeroMQ masih lebih baik.
8. Kesimpulan dan Saran
8.1. Kesimpulan
Kesimpulan yang dapat diambil antara lain sebagai berikut. 1. Telah diimplementasikan satu aplikasi bisnis
pulsa elektrik dengan menggunakan ZeroMQ. 2. Pengujian menunjukkan kinerja latency ZeroMQ
dengan satu client tidak lebih baik dari pada socket linux, dan lebih baik dengan lebih dari satu client.
3. Dengan satu client atau lebih kinerja throughput ZeroMQ lebih baik dari socket linux.
8.2. Saran
Saran-saran yang dapat diberikan untuk pengembangan selanjutnya adalah sebagai berikut. 1. Dengan penambahan jenis operator
telekomunikasi seluler dan penambahan proses pengiriman data transaksi ke operator telekomunikasi seluler menjadikan sistem ini dapat diimplementasikan pada bisnis pulsa elektrik.
2. Proses login dapat ditambahkan untuk menjaga keamanan dalam komunikasi data antar server.
3. Penambahan sistem komunikasi persisten membuat sistem ini menjadi lebih reliabel.
9. Daftar Pustaka
[1] http://www.webopedia.com/TERM/m/middleware.html
[2] Wikipedia 2009. "Middleware". <URL: http://en.wikipedia.org/wiki/Middleware>
[3] David E. Bakken. 2003. "Middleware". <URL: http://www.eecs.wsu.edu/~bakken/middleware.htm>
[4] Zeromq 2009. "Background to AMQP". <URL: http://www.zeromq.org/whitepapers:amqp-analysis>
[5] Middleware 2009. "Message Queuing Middleware". <URL: http://www.middleware.org/general/mqm.html>
[6] Wikipedia 2009. "Message-oriented middleware". <URL: http://en.wikipedia.org/wiki/Message_Oriented_Middleware>
[7] "Message-oriented middleware". <URL: http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9999aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&patp=dsonline/topics/middleware&file=intro_MOM.xml&xsl=article.xxs>
[8] Markku Korhonen. 1997. "Message Oriented Middleware (MOM)". Tik- 110.551 Internetworking Seminar, Department of Computer Science, Helsinki University of Technology. <URL: http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/mqs.htm>
[9] Andrew S. Tanenbaum, Maarten Van Steen. 2002. "Distributed Systems Principles and Pradigms": Prentice-Hall, Inc.
[10] Zeromq 2009. "What's Zeromq?". <URL: http://www.zeromq.org/>
[11] Zeromq 2009. "Y-suite". <URL: http://www.zeromq.org/whitepapers:y-suite>
[12] Zeromq 2009. "Instan Messaging". <URL: http://www.zeromq.org/code:examples-chat>
[13] Apache log4cxx 2010. "Short introduction to Apache log4cxx". <URL: http://logging.apache.org/log4cxx/index.html>
[14] http://www.cplusplus.com/doc/tutorial/ [15] http://www.infernodevelopment.com/perfect-c-
string-explode-split
Top Related